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Executive  Summary 


Background 

Interoperability  between  Command,  Control, 
Communications,  Computers,  and  Intelligence 
(C4I)  and  Modeling  and  Simulation  (M&S)  sys¬ 
tems  is  one  of  the  greatest  challenges  to  the 
M&S  community  today.  The  Army  needs  simu¬ 
lations  to  train  its  forces,  and  to  provide  testing 
environments  for  new  systems.  But  to  use  simu¬ 
lations  with  C4I  systems,  the  Army  has  been 
developing  point-to-point  software  interfaces. 

In  the  past  10  years,  M&S  and  C4I  standards  and 
development  practices  have  diverged  signifi¬ 
cantly.  The  two  communities  now  use  quite  dif¬ 
ferent  data  models  as  well  as  different  architec¬ 
tures  (M&S  uses  the  High  Level  Architecture 
(HLA)  while  C4I  uses  the  Defense  Information 
Infrastructure  Common  Operating  Environment 
(DII  COE)).  Data  model  compatibility  is  a  fun¬ 
damental  issue.  Major  interoperability  problems 
arise  when  there  are  data  exchange  requirements 
for  C4I-M&S  interoperation  that  are  not  sup¬ 
ported  by  one  side  of  the  exchange.  Similarly, 
interoperability  problems  occur  if  data  represen¬ 
tations  differ  significantly  between  systems,  al¬ 
though  these  problems  are  not  as  bad  as  those 
caused  by  unsupported  data  exchange  require¬ 
ments. 

It  is  desirable  to  have  data  compatibility  to  the 
fullest  extent  possible.  General  solutions  to  in¬ 
teroperability  have  not  emerged  to  date,  and  lack 
of  data  compatibility  appears  to  be  a  principal 
reason  why.  Beginning  in  1993,  with  the  third 
Army  Tactical  Command  and  Control  Systems 
test,  a  “cottage  industry”  of  custom,  point-to- 
point  C4I-M&S  interfaces  has  grown  up  around 
the  Army's  family  of  Command  and  Control 
(C2)  systems.  Reuse,  standardization,  and  inter¬ 
operability  were  often  not  key  design  criteria,  so 
most  of  these  interfaces  link  a  specific  simulation 
to  a  specific  C4I  system  and  typically  handle 
only  a  small  subset  of  the  messages  or  data  the 
“targef’ — or  stimulated — C4I  system  can  accept 
and/or  the  simulation  can  pass. 


Purpose 

This  report  addresses  the  issue  of  developing 
common  data  models  for  Army  C4I  and  M&S 
systems.  It  provides  a  base  case  study  of  com¬ 
patibility  (or  extent  of  alignment)  between  exist¬ 
ing  C4I  and  M&S  data  models.  This  study  serves 
the  purpose  of  identifying  compatibility  (or 
alignment)  problems  which  need  to  be  resolved 
in  order  to  enable  development  of  common  data 
models  for  C4I  and  M&S  systems.  In  addition,  it 
makes  recommendations  on  addressing  these 
problems  in  ways  that  move  C4I  and  M&S  mod¬ 
eling  closer  to  the  goal  of  common  modeling 
standards. 

Methodology 

The  study  focuses  on  the  principal  formally  sanc¬ 
tioned  data  standards  in  the  Army  C4I  and  M&S 
domains.  In  the  C4I  domain,  this  is  the  Army 
Integrated  Core  Data  Model  (AICDM)  of  the 
Office  of  the  Director  for  Information  Services 
for  C4  (ODISC4).  The  AICDM  is  a  relational 
model,  and  is  the  Army’s  data  standard  for  tacti¬ 
cal  databases.  In  the  M&S  domain,  the  principal 
data  standards  are  expressed  in  the  standard  ob¬ 
jects  of  the  Object  Management  Standards  Cate¬ 
gory  (OMSC)  developed  under  the  auspices  of 
the  Army  Model  and  Simulation  Office 
(AMSO).  The  OMSC  consists  of  a  set  of  stan¬ 
dard  objects,  each  of  which  presents  an  object- 
oriented  model  of  some  facet  of  simulation  data 
and  functionality.  All  of  the  currently  developed 
OMSC  standard  objects  (Unit,  Platform,  and 
Location)  were  analyzed. 

The  study  performed  an  analysis  of  alignment  to 
support  an  assessment  of  the  potential  compati¬ 
bility  and  interoperability  of  systems  based  on 
the  examined  data  standards.  The  report  defines 
suitable  technical  concepts  of  alignment  in  order 
to  enable  quantitative  assessments  of  alignment 
between  these  data  models.  Roughly  speaking, 
these  definitions  declare  that  the  AICDM  and  the 
OMSC  are  in  alignment  to  the  extent  that 
AICDM  modeling  elements  cover  the  data  re- 
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quirements  implicit  in  the  OMSC  standard  ob¬ 
jects. 

The  study  assigned  each  modeling  element  a 
degree  of  alignment,  the  pereentage  of  possible 
eoverage.  Ideally,  each  OMSC  element  ought  to 
have  a  100%  degree  of  alignment  with  an 
AICDM  element,  meaning  that  these  elements 
model  the  same  data,  and  allowing  an  AICDM- 
based  system  and  an  OMSC-based  system  to 
interoperate  with  respect  to  these  elements.  But, 
if  an  OMSC  element  has  no  counterpart  in  the 
AICDM,  there  is  0%  degree  of  alignment.  Or  the 
degree  of  alignment  may  be  between  0%  and 
100%,  as  when  the  AICDM  and  the  OMSC 
model  similar  types  of  data,  but  they  do  not 
mateh  exactly.  We  expeet  that  degrees  of  align¬ 
ment  lower  than  100%  entail  significant  amounts 
of  effort  to  aehieve  interoperability. 

Assessment  of  alignment  between  these  two 
models  is  not  straightforward.  For  one  thing,  the 
OMSC  is  a  high-level  model  of  architectural 
design.  The  OMSC  standard  objects  are  defined 
fairly  informally  relative  to  interoperability  as¬ 
sessment  needs.  In  any  event,  their  definitions 
are  incomplete.  For  another,  the  AICDM  is  a 
relational  data  model  expressed  in  IDEFIX, 
whereas  the  OMSC  uses  object  oriented  models 
based  on  the  Unified  Modeling  Language 
(UML).  Finally,  the  models  vary  widely  in  seope 
and  level  of  detail.  The  AICDM  has  approxi¬ 
mately  370  entities  in  all  views.  The  OMSC  ob- 
jeets  developed  thus  far  have  only  22  elasses, 
where  elasses  eorrespond  in  our  alignment  to 
entities. 

As  implied  above,  our  analysis  of  alignment  be¬ 
tween  the  AICDM  and  the  OMSC  is  unidirec¬ 
tional.  It  focuses  on  the  extent  to  which  AICDM 
modeling  elements  cover  the  data  requirements 
implicit  in  the  OMSC  standard  objects.  It  does 
not  cover  the  extent  to  which  OMSC  standard 
objects  can  model  the  data  that  can  be  repre¬ 
sented  by  AICDM  modeling  elements.  We  chose 
this  direction  for  several  reasons.  First,  it  aids 
identification  of  any  extensions  to  the  AICDM 
that  might  be  required  to  accommodate  M&S 
data  requirements  (an  objective  of  the  task  sup¬ 
porting  this  report).  And,  it  is  already  known  that 
most  of  the  much  greater  number  of  AICDM 
data  elements  are  not  covered  by  the  object  mod¬ 
els  of  the  OMSC. 

In  some  cases,  assumptions  about  OMSC  data 
elements  are  made  where  these  seemed  war¬ 
ranted  by  their  (ambiguous)  informal  descrip¬ 


tions.  These  assumptions  (e.g.,  data  types,  range 
of  enumerated  values)  affect  the  alignment  as¬ 
sessments  in  this  report.  Ambiguities  and  other 
problems  in  the  OMSC  standard  leave  open  the 
possibility  that  simulation  developers  will  inter¬ 
pret  the  OMSC  standards  in  ways  that  lead  to 
decreased  degrees  of  alignment  in  actual  imple¬ 
mentations  of  the  models.  In  addition,  the  chosen 
direction  of  alignment  is  not  representative  of  the 
reverse  direction  (from  the  AICDM  to  the 
OMSC  objects)  which  because  of  the  AICDM’s 
greater  size  is  much  less  well  aligned.  Hence,  an 
overall  alignment  assessment  of  these  models  (in 
both  directions)  would  yield  much  lower  levels 
of  alignment. 

Findings 

The  summary  results  of  this  alignment  assess¬ 
ment  are  presented  in  Tables  ES-1,  ES-2,  and 
ES-3.  These  summary  results  are  based  on  the 
detailed  analyses  of  alignment  between  individ¬ 
ual  entities  and  classes  provided  in  this  report. 

The  numbers  in  these  tables  are  subjective, 
largely  because  of  ambiguities  in  the  OMSC 
specifications.  The  degree  of  alignment  at  the 
end  of  each  table  is  an  average;  as  such,  it  can  be 
expected  to  contain  some  error.  The  IDA  study 
team  has  calculated  the  standard  deviation  of  the 
error.  It  is  included  in  the  tables.  Thus,  the  value 
of  56%  in  Table  ES-1  really  means  a  95%  confi¬ 
dence  level  that  the  value  is  between  44%  and 
68%. 

Given  the  ambiguities  in  the  OMSC  specifica¬ 
tions  it  may  be  possible  to  enhance  the  alignment 
by  adopting  other  interpretations  of  what  the 
objects,  classes  and  methods  purport  to  represent 
and  accomplish. 

Analysis  of  these  results  clearly  show  that  the 
Army  has  a  serious  problem  with  data  model 
alignment  between  the  C4I  and  M&S  domains. 
Even  if  next  generation  training  and  testing 
simulations  are  built  using  standard  simulation 
objects,  developers  will  have  to  craft  interfaces 
to  transform  data  and,  in  many  cases,  create  data 
that  is  missing  from  the  other  domain.  The  im¬ 
pact  for  acquisition  of  systems  is  significant. 
Millions  of  dollars  will  have  to  be  spent  after  the 
systems  are  developed  to  interface  incompatible 
models.  These  costs  are  avoidable  to  the  extent 
that  we  can  improve  the  degree  of  alignment  of 
data  prior  to  implementation. 
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Table  ES-1.  Summary  of  Unit  Standard  Object  Degree  of  Alignment 


OMSC  Class 

Degree  of  Al ignment  to  the  Al C  DM 

Unit 

51% 

Unite  eometry 

50% 

Intei 

37% 

Communications 

81% 

SystemGroup 

100% 

Piatform 

55% 

Piatforminfo 

25% 

Attrition 

75% 

Logistic 

75% 

Maintenance 

42% 

Suppiy 

75% 

C2 

0% 

Unit  Standard  Object  Degree  of  Alignment:  56% 
Standard  deviation:  6% 


Table  ES-2.  Summary  of  Platform  Standard  Object  Degree  of  Alignment 


OMSC  Class 

Degree  of  Alignment  to  the  Al  CDM 

P  iatform 

62% 

Sensor 

30% 

Weapon 

50% 

Movement 

25% 

Logistics 

75% 

Suppiy 

55% 

Maintenance 

25% 

Crew 

100% 

Communications 

81% 

Carrier 

85% 

PiatformFrame 

25% 

FrameComponent 

25% 

Piatform  Standard  Object  Degree  of  Alignment:  55% 
Standard  deviation:  6% 


T able  E  S-3.  Summary  of  Location  Standard  Object  Degree  of  Alignment 


OMSC  Class 

Degree  of  Alignment  to  the  AlCDM 

Location 

37% 

Locai 

0% 

LatLon 

75% 

Location  Standard  Object  Degree  of  Alignment:  37% 
Standard  deviation:  4% 
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Recommendations 

The  recommendations  from  this  study  are  in 
three  classes:  general  recommendations,  recom¬ 
mendations  for  the  OMSC  objects,  and  recom¬ 
mendations  for  the  AICDM. 

The  general  recommendation  is  that  both  the  C4I 
and  M&S  communities  work  towards  a  common 
data  model  in  the  area  of  overlap  between  C4I 
and  M&S  requirements.  The  analysis  shows  that 
this  is  possible,  but  significant  differences  re¬ 
main  to  be  resolved  that  go  beyond  the  current 
OMSC  &  AICDM  models.  This  report  found  no 
theoretical  reasons  why  C4I  data  cannot  be  rep¬ 
resented  in  an  M&S  model  or  why  M&S  data 
cannot  be  represented  in  a  C4I  data  model.  C4I 
data  models  are  more  mature,  so  the  primary 
responsibility  currently  falls  upon  the  M&S 
community  to  move  towards  standard  representa¬ 
tions  that,  at  the  very  least,  can  be  aligned  with 
C4I  data.  The  M&S  OMSC  standards  were  in¬ 


sufficient  in  detail,  insufficient  in  scope  and  did 
not  structurally  align  to  the  AICDM.  By  com¬ 
parison,  only  relatively  minor  changes  to  the 
AICDM  are  needed  to  accommodate  M&S  data 
requirements. 

Recommendations  for  the  OMSC:  The  report 
lists  34  specific  recommendations  to  change  the 
existing  OMSC  Standard  Object  classes.  How¬ 
ever,  it  also  recommends  that  more  sweeping 
revisions  be  made  to  correct  structural  misalign¬ 
ments  and  other  problems  documented  in  Ap¬ 
pendix  B,  Critique  of  the  OMSC  Object  Model. 

Recommendations  for  the  AICDM:  The  report 
lists  18  specific  recommendations  to  change  the 
AICDM.  Many  of  these  are  already  in  data  pro¬ 
posal  packages  submitted  to  the  Defense  Infor¬ 
mation  Systems  Agency  (DISA),  and  are  ex¬ 
pected  to  be  incorporated  in  future  versions  of 
that  data  model. 
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1.  Introduction 


Command,  Control,  Communications,  Computers,  and  Intelligence  (C4I)  and  Modeling 
and  Simulation  (M&S)  are  different  communities  with  different  backgrounds.  There  is 
currently  little  interoperability  between  C4I  and  M&S  systems.  It  is  not  easy  to  embed 
C4I  functionality  into  an  M&S  system,  or  vice  versa.  Yet  interoperability  would  prove 
tremendously  useful  to  both  communities.  The  following  examples  are  often  cited  as 
benefits  of  interoperability: 

•  Simulation-based  acquisition  (i.e..  Requirements  Development  and  Analysis, 
Testing,  and  Training) 

•  Development  of  doctrine  and  tactics  techniques,  and  procedures 

•  Embedded  training  (both  individual  and  collective) 

•  Course  of  action  development  and  analysis 

•  Mission  planning  and  rehearsal 

•  Execution  monitoring 

The  Army  spends  around  ten  million  dollars  annually  to  achieve  and  maintain  limited  in¬ 
teroperability  It  has  implemented  custom  software  interfaces  linking  specific  M&S  and 
C4I  systems.  These  interfaces  have  not  proven  useful  to  other  programs,  which  is  not 
surprising  because  reuse,  standardization,  and  interoperability  were  not  part  of  the  inter¬ 
faces’  design  criteria.  A  general  purpose  approach  to  interoperability  is  one  of  the  greatest 
challenges  to  the  M&S  community  today. 

1.1  Purpose  of  the  Document 

This  report  looks  at  a  key  area  of  C4I/M&S  interoperability  that  has  not  been  recognized 
to  date.  This  area  is  data  model  alignment:  the  ability  for  C4I  and  M&S  systems  to  share 
and  exchange  data  based  on  a  common  model  of  the  data  each  system  manipulates.  The 
premise  of  this  report  is  simple.  If  data  representation  in  M&S  systems  and  C4I  systems 
is  very  different,  then  interoperability  will  be  difficult.  This  report  provides  a  basis  for 
assessing  data  model  alignment,  and  makes  recommendations  for  improving  data  model 
alignment  when  appropriate.  This  basis  is  termed  degree  of  alignment.  Degree  of  align¬ 
ment  is  a  quantitative  measure  of  the  interoperability  between  a  C4I  data  model  and  an 
M&S  data  model. 

The  report  assesses  the  degree  of  alignment  between  two  data  models: 

•  The  Army  Object  Management  Standards  Category  (OMSC)  standard  for  Unit, 
Platform,  and  Location  objects  from  the  M&S  domain. 

•  The  Army  Integrated  Core  Data  Model  (AICDM),  the  standard  C4I  data  model 
developed  for  Army  tactical  databases. 

The  purpose  of  the  assessment  is  to  study  the  feasibility  of  using  these  two  models  as  the 
basis  for  future  interoperability  work.  These  models  are  important  emerging  standards 
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that,  it  is  hoped,  will  be  used  in  the  design  and  implementation  of  many  systems.  If  the 
AICDM  and  the  OMSC  are  aligned,  future  M&S  and  C4I  system  developers  who  based 
their  systems  on  the  AICDM  or  the  OMSC  will  have  a  head  start  on  interoperability.  This 
report  draws  eonelusions  from  the  assessment  on  direetions  for  these  models  to  evolve 
that  will  promote  interoperability. 

1.2  Intended  Audience 

There  are  three  intended  audienees  for  this  doeument: 

•  AICDM  (and  other  C4I  model)  designers  who  want  interoperability  with  M&S 
systems. 

•  OMSC  (and  other  M&S  model)  designers  who  want  interoperability  with  C4I 
data  models. 

•  High-level  DoD  offieials  responsible  for  establishing  direetions  for  C4I  and 
M&S  systems. 

This  doeument  assumes  the  reader  is  familiar  with  the  IDEFIX  notation  for  entity- 
relationship  diagrams  and  the  Unified  Modeling  Language  (UML)  notation  for  elass  hier- 
arehies.  [NIST  1993]  and  [Booeh  1996]  provide  useful  introduetions  and  referenees  to 
these  notations. 

1.3  Background 

C4I/M&S  interoperability  is  mainly  aeeomplished  by  software  interfaces  established  be¬ 
tween  speeifle  systems.  The  development  of  C4I/M&S  interfaees  has  not  been  one  of  the 
primary  design  requirements  for  either  type  of  system.  Most  of  the  existing  C4I  interfaees 
to  M&S  have  been  developed  as  a  separate  eomponent,  added  on  after  initial  develop¬ 
ment.  Existing  interfaees  typieally  handle  a  small  subset  of  the  messages  or  data  neees- 
sary  for  interoperability,  requiring  signifieant  human  intervention  to  aehieve  realism  for 
the  training  audienee  in  an  exereise.  M&S  systems,  for  instanee,  rarely  handle  free  text 
messages  or  eonsider  how  a  message  is  earned  (i.e.,  eommunieation  effeets).  C4I  systems 
have  been  subjeet  to  different  design  eonstraints  than  M&S  systems,  resulting  in  different 
standards,  message  formats  and  protoeols.  Sinee  any  interfaee  between  the  systems  must 
align  these  differenees,  the  interfaee  ean  beeome  quite  eomplex,  and  eostly  to  develop 
and  maintain. 

Legaey  systems  and  the  laek  of  standard  arehiteetures  have  worked  together  in  the  past  to 
frame  the  issue  of  C4I  to  M&S  interoperability  as  one  of  interfaees.  We  believe  that  these 
interfaees,  while  neeessary,  are  only  one  eomponent  of  interoperability.  Reeent  interfaee 
projeets  sueh  as  the  Modular  Reeonfigurable  C4I  Interfaee  (MRCI)  [LSCZ  1998]  provide 
lessons  learned  that  have  shaped  our  approaeh.  Complete  interoperability  can  only  be  ad¬ 
dressed  by  consideration  of  several  dijferent  aspects  such  as  standards,  architectures, 
data  models  and  processes. 

In  reeent  years  there  has  been  some  eoneerted  effort  to  devise  systematie  approaehes  to 
interoperability.  One  of  these  approaehes  has  yielded  a  framework  that  lays  out  several 
foundational  areas  in  whieh  progress  must  be  made  before  interoperability  ean  be 
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achieved  [HS  2000].  This  framework,  shown  in  Figure  1,  identifies  the  necessary  compo¬ 
nents  for  a  comprehensive  solution: 

•  Architectures  Alignment 

•  Common  Data/Object  Models 

•  Common  Standards 

•  Processes  to  manage  and  align  all  efforts  and  respective  results  -  and  as  a  result 
of  the  above, 

•  Reusable  Component  Interfaces  and  shared  solutions 

The  approach  of  the  proposed  Architecture  Alignment  recognizes  that  there  are  many 
ways  to  partition  the  “solution  space”.  The  C4I  community  has  developed  the  Defense 
Information  Infrastructure  Common  Operating  Environment  (DII  COE)  architectures. 
The  simulation  community  has  the  High  Eevel  Architecture  (HEA)  [HEA2000].  These 
architectures  directly  impact  the  technical  basis  upon  which  C4I  and  simulation  systems 
are  built.  Alignment  of  architectures  contrasts  and  resolves  the  differences  in  how  archi¬ 
tectures  compartmentalize  the  “solution  space”  of  the  system(s)  or  system  of  systems. 

Historically,  the  alignment  of  Common  Data  Models  (C4I  systems)  with  Object  Models 
(simulation  systems)  is  often  ignored  [HB  1999].  However,  having  M&S  applications  use 
the  same  or  similar  model  representation  as  the  C4I  system  with  which  they  exchange 
data  obviously  minimizes  translation.  Without  both  model  and  architecture  alignment,  the 
efforts  represented  by  the  rest  of  the  blocks  comprising  the  “house  diagram”  of  Figure  1 
are  limited  to  isolated  interface  successes  such  as  seen  today  between  stovepipe  systems. 


The  development  and  use  of  Common  Standards  is  another  aspect  of  the  alignment  ap¬ 
proach  that  must  be  worked  into  M&S  system  designs.  Making  sense  of  where  and  how 
to  apply  standards  relies  primarily  on  work  being  done  on  the  architecture  and  data/object 
model  alignment.  Since  little  architecture  and  model  alignment  work  has  been  done,  it 
has  often  been  difficult  to  set  and  use  meaningful  standards  to  assist  interoperability  chal¬ 
lenges. 


Processes 
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Reusable  Component 
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Common 
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Models 


Common 

Standards 


Architecture 
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Figure  1.  C4I/M&S  Interoperability  Components 
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Notice  that  the  proposed  approach  sets  the  Reusable  Component  Interfaces  on  top  of,  and 
therefore  dependent  upon,  the  blocks  below  it.  Compared  to  architectures,  models  and 
standards,  the  interfaces  area  has  been  a  hotbed  of  activity.  One  answer  to  this  apparent 
paradox  is  that  interfaces  can  provide  short-term  solutions  that  are  easier  to  envision  and 
allow  quicker  successes  in  a  world  of  disparate  systems.  Translators  in  these  interfaces 
help  to  convert  data  between  systems,  but  never  really  remove  basic  underlying  incom¬ 
patibilities  of  model  representation  or  architecture  misalignment  in  the  original  systems. 

Finally,  Shared  Solutions  between  C4I  and  simulations — the  roof  of  the  house  diagram  in 
Figure  1 — is  supported  by  the  work  of  all  the  blocks  below  it  including  the  Processes  for 
Alignment,  which  provides  policy  and  procedures  for  evolving  the  other  house  blocks. 

Efforts  such  as  HLA  have  given  those  interested  in  interoperability  the  basis  to  pursue 
other  areas.  This  paper  focuses  on  the  Common  Data/Object  Models  box.  It  addresses 
data  alignment  between  the  two  models — that  is,  knowledge  of  common  data  used  in 
both  M&S  and  C4I  systems,  along  with  the  ability  to  share  that  data. 

1.4  Data  Model  Alignment 

The  focus  of  this  document  is  on  data  model  alignment.  Data  model  alignment  is  a  key 
component  of  interoperability.  Systems  that  use  similar  data  models  can  share  data  easily. 
Suppose  system  A  wants  to  incorporate  functionality  from  system  B.  If  their  data  models 
are  aligned,  system  A  can  supply  the  data  needed  to  invoke  B’s  functions;  also,  system  A 
can  interpret  the  results  of  B’s  functions  in  terms  of  structures  it  possesses.  But  if  their 
data  models  are  not  aligned,  system  A  might  lack  all  the  necessary  data  to  invoke  one  of 
B’s  functions.  System  A  might  have  to  manufacture  the  data  by  making  limiting  assump¬ 
tions,  thereby  reducing  the  usefulness  of  interoperability  with  B.  Or  it  might  have  to  ob¬ 
tain  the  data  from  another  source,  such  as  another  system  (costly)  or  a  human  (slow).  And 
if  system  As  data  model  does  not  account  for  all  the  data  that  B  generates,  system  A  must 
either  be  re-implemented  or  discard  potentially  valuable  results. 

Achieving  data  model  alignment  while  ignoring  the  other  components  of  Figure  1  will 
not  achieve  C4I/M&S  interoperability.  Each  component  has  a  necessary  role.  Moreover, 
even  after  achieving  data  model  alignment,  an  organization  can  expect  to  devote  consid¬ 
erable  resources  to  achieving  full  interoperability.  Nevertheless,  achieving  data  model 
alignment  is  a  significant  step  towards  interoperability. 

Currently,  there  is  not  much  data  model  alignment  between  legacy  C4I  and  M&S  sys¬ 
tems.  Much  of  the  disparity  can  be  attributed  to  the  different  requirements  and  implemen¬ 
tation  technologies  that  drive  each  category  of  system.  Many  C4I  systems  are  information 
systems.  They  have  near  real  time,  but  not  real  time,  performance  constraints.  They  have 
taken  advantage  of  this  relative  freedom  to  use  commercial  database  management  sys¬ 
tems  for  data  storage  and  data  structures.  This  design  decision  is  excellent  from  an  eco¬ 
nomic  standpoint.  Whatever  the  drawbacks  of  commercial  DBMSs — certainly  no  one  has 
ever  claimed  their  primary  objective  is  to  optimize  run-time  performance — they  provide  a 
powerful  data  modeling  tool  that  can  be  used  throughout  software  design  and  implemen¬ 
tation. 
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M&S  systems,  as  a  rule,  have  less  freedom.  Their  designers  sometimes  find  that  eommer- 
eial  DBMSs  are  too  slow  when  applied  to  large  data  sets.  Many  M&S  systems  have  met 
their  performanee  requirements  by  implementing  their  own  data  models  and  data  man¬ 
agement  subsystems. 

1.5  Standard  Data  Models 

Both  eamps  have  made  efforts  at  standardization.  Their  motivation  has  not  been  interop¬ 
erability  between  the  C4I  and  M&S  worlds  so  mueh  as  reuse  within  their  own  worlds. 
For  example,  all  future  Army  Battle  Command  Systems  (ABCS)  will  use  a  version  of  the 
Joint  Common  Data  Base  (JCDB)  data  model  to  promote  interoperability  of  similar  fune- 
tions  (see  Seetion  2  for  baekground  on  these  models).  Another  example  in  the  M&S 
world  is  the  Army  Materiel  Systems  Analysis  Aetivity’s  development  of  Objeet  Manage¬ 
ment  Standards  Category  (OMSC),  an  objeet-oriented  eneapsulation  of  M&S  funetional- 
ity.  The  OMSC  eonsists  of  a  set  of  standard  objeets,  eaeh  of  whieh  presents  an  objeet- 
oriented  view  of  some  faeet  of  simulation  data  and  funetionality.  The  OMSC  standard 
objeets  used  in  this  report  are  diseussed  in  more  detail  in  Seetion  3. 

Simulations  have  traditionally  used  highly  speeialized  knowledge  representations  to 
aehieve  aeeeptable  runtime  performanee.  Standard  representations  have  been  slow  to 
emerge  due  to  the  differing  system  eomponents  of  simulations  (software  and  hardware). 
The  HLA  addresses  interoperability  between  simulations  through  speeifieation  of  a  Fed¬ 
eration  Objeet  Model  (FOM).  The  FOM  allows  diverse  simulations  to  share  eertain 
elasses  of  information  during  exeeution.  However  the  FOM  only  is  used  for  transferring 
data  between  models  at  run-time,  and  is  not  neeessarily  used  when  a  system  is  being 
built.  The  purpose  of  the  OMSC  standard  objeets  is  to  allow  developers  to  use  a  eommon 
representation  that  saves  development  time  and  is  a  better  representation. 

Simulations  use  many  different  representations  that  are  analogous  to  data  models.  In  the 
ease  of  eommon  Army  simulations,  these  representations  in  many  instanees,  do  not  align 
with,  or  map  to,  the  JCDB.  If  there  is  a  mismateh  between  the  simulation  and  C4I  stan¬ 
dards,  then  software  translators  will  have  to  be  built  to  align  the  data.  Sueh  translation 
software  and  assoeiated  interfaees  are  very  eostly  and  reduee  interoperability  through 
laek  of  funetionality  In  addition,  if  data  elements  are  missing  in  simulations  that  are  util¬ 
ized  in  real  world  systems,  interfaees  beeome  mueh  more  eomplex,  as  they  must  both 
ereate  and  synehronize  sueh  data. 

The  target  data  model  in  the  Army  C4I  eommunity  is  the  Army  Integrated  Core  Data 
Model  (AICDM).  Seetion  2  gives  a  detailed  overview  of  the  AICDM.  Briefly,  the 
AICDM  is  a  relational  data  model  based  on  several  existing  models,  ineluding  the  JCDB, 
the  C2  Core  Data  Model,  and  the  Army  Land  C2  Information  Exehange  Data  Model 
(formerly  ealled  the  Generie  Hub  Version  4,  or  GH4)  developed  to  support  multinational 
operations.  The  AICDM  is  the  Army’s  target  model  for  taetieal  databases.  It  is  broader 
than  the  JCDB.  The  AICDM  must  aeeommodate  both  inter-serviee  and  international  re¬ 
quirements,  whereas  the  JCDB  is  more  oriented  towards  ABCS  systems,  and  more  ori¬ 
ented  towards  the  physieal  level.  Although  the  two  models  are  different,  they  use  many  of 
the  same  data  entities  and  the  degree  of  alignment  determined  in  this  paper  would  proba- 
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bly  not  differ  substantially  if  the  JCDB  were  used  instead  of  the  AICDM,  at  least  with 
respeet  to  the  areas  of  C4I/M&S  overlap. 

One  eomplieating  issue  in  the  analysis  presented  in  this  report  is  that  the  AICDM  and  the 
HLA  use  different  paradigms.  The  C4I  eommunity  is  using  relational  data  base  modeling. 
The  M&S  eommunity  is  primarily  using  objeet  oriented  modeling.  There  are  no  agreed- 
upon  ways  to  eompare  the  two.  Rather  than  eomparing  an  entity  to  an  entity  whieh  would 
be  possible  if  both  standard  models  were  based  on  the  same  relational  paradigm,  we  must 
deeide  what  to  eompare  an  entity  to,  whieh  adds  an  additional  layer  to  the  analysis. 

1.6  Assumptions 

Several  eonsiderations  have  shaped  this  report.  The  first  is  that  the  OMSC  standard  objeet 
speeifieations  do  not  eontain  suffleient  detail  to  perform  a  full  analysis  of  alignment.  The 
AICDM  provides  speeifieations  for  its  attributes  giving  data  types  and  enumerated  val¬ 
ues.  The  OMSC  speeifieations  do  not  provide  the  equivalent  information.  Seetion  4  de¬ 
tails  how  we  have  dealt  with  this  problem,  but  it  means  that  in  many  eases,  we  only  pro¬ 
vide  reeommendations  for  how  to  modify  the  AICDM.  Due  to  the  above-mentioned  laek 
of  detail  in  the  OMSC  speeifieations,  the  IDA  study  team  had  to  assume  a  eertain  inter¬ 
pretation  for  the  OMSC  standard  objeets.  Unfortunately,  it  is  unlikely  that  the  different 
users  of  the  OMSC  standard  objeets  will  all  agree  upon  one  interpretation,  mueh  less  the 
one  that  has  been  adopted  here. 

A  seeond  assumption  is  one  of  seope.  The  AICDM  has  377  entities,  while  the  OMSC  has 
22  elasses  (the  analog  to  relational  data  entities).  Due  to  this  large  mismateh,  only  the 
OMSC  elasses  have  been  eompared  to  equivalent  AICDM  entities,  and  no  attempt  has 
been  made  to  find  matehes  in  the  OMSC  for  the  numerous  AICDM  entities.  This  has  the 
effeet,  as  with  the  first  assumption,  of  faeilitating  the  alignment  analysis  over  what  it 
would  be  if  we  did  not  make  either  of  these  assumptions. 

1.7  Organization  of  this  Document 

This  doeument  is  organized  as  follows: 

•  Seetion  1  (this  seetion)  introduees  the  problems  addressed  by  the  report,  the  re¬ 
port’s  purpose  and  seope,  and  the  report’s  intended  audienee. 

•  Seetions  2  and  3  provide  overviews  of  the  AICDM  and  the  OMSC  models, 
respeetively.  The  seetions  highlight  faeets  of  eaeh  model  that  relate  to 
alignment.  These  seetions  are,  however,  only  overviews.  Readers  seeking 
details  should  eonsult  the  referenees. 

•  Seetion  4  presents  a  preeise  definition  of  what  alignment  means  in  this  report. 

•  Seetion  5  gives  the  proeess  used  to  assess  alignment.  The  proeess  is  intended  to 
be  repeatable  and  reusable.  In  other  words,  it  ean  be  applied  as  the  AICDM  and 
the  OMSC  evolve. 

•  Seetion  6  presents  the  results  of  applying  the  proeess  to  the  OMSC  model.  See¬ 
tion  6  eomputes  the  degree  to  whieh  the  AICDM  and  the  OMSC  are  eurrently 
aligned. 
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•  Section  7  lists  recommendations  for  changes  to  the  AICDM  and  the  OMSC, 
based  on  the  results  from  Section  6. 

•  Appendix  A  provides  details  that  underlie  the  results  from  Section  6. 

•  Appendix  B  gives  a  critique  of  the  OMSC  standard  objects  and  the  object 
model  used  to  describe  them. 

•  Appendix  C  lists  the  AICDM  views  extant  at  the  time  this  report  was  written, 
and  the  status  of  each  view. 

•  Appendix  D  presents  an  alternate  categorization  of  recommendations  in  Sec¬ 
tion  7. 

•  This  report  analyzed  the  AICDM  as  of  March  2000.  Appendix  E  describes  rec¬ 
ommendations  in  this  report  that  have  been  implemented  in  more  recent  ver¬ 
sions  of  the  AICDM. 
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2.  Overview  of  the  AlC DM 


2.1  Background 

With  the  demise  of  the  Soviet  threat  in  1989  and  the  eoneomitant  budget  reduetions  in  the 
90 ’s,  DoD  realized  the  need  to  eliminate  stovepipe  systems  and  to  take  advantage  of 
eommon  hardware  and  software.  This  approaeh  was  extended  to  the  data  being  eolleeted 
and  maintained  by  the  Serviees  and  ageneies,  and  DoD  launehed  the  standardization 
proeess  under  the  DoD-8320.1  guidelines  [DoD  1991]. 

The  first  model  developed  to  eapture  the  data  requirements  for  the  whole  DoD  enterprise, 
the  DoD  Enterprise  Model,  did  not  have  a  very  robust  C2  eomponent.  The  Army  pro¬ 
posed  that  the  data  model  it  had  been  developing  for  its  multinational  operations,  namely 
the  Generie  Hub,  be  adopted  and  ineorporated  into  the  DoD  enterprise  data  model  (later 
renamed  the  DoD  Data  Model  (DDM),  and  more  reeently  the  DoD  Data  Arehiteeture 
(DDA)).  The  Defense  Information  Systems  Ageney  (DISA)  was  tasked  to  perform  the 
integration  and  the  resulting  struetures  eonstituted  the  initial  version  of  the  Command  and 
Control  Core  Data  Model  (C2CDM). 

From  1993-1997  the  C2CDM  eontinued  to  evolve  and  beeame  the  mandated  model  for 
all  new  C2  systems,  both  by  the  Joint  Teehnieal  Arehiteeture  (JTA)  [DoD  1999]  and  the 
Joint  Teehnieal  Arehiteeture  -  Army  (JTA- A)  [Army  2000].  It  was  also  used  as  the  point 
of  departure  for  the  JCDB,  the  model  used  to  provide  data  interoperability  to  the  ABCS. 

However,  the  Army  realized  that  many  of  the  struetures  eontained  in  the  C2CDM  were 
not  keeping  paee  with  its  evolving  data  requirements,  partieularly  with  respeet  to  the  later 
versions  of  its  C2  model  for  multinational  operations,  the  Generie  Hub,  nor  were  the 
teehnieal  errors  the  C2CDM  eontained  being  eorreeted  in  a  timely  manner  by  DISA.  As  a 
result,  the  Army  began  a  new  effort  to  upgrade  and  expand  the  C2CDM,  with  a  view  to 
refleet  these  new  data  requirements  as  part  of  the  DoD  standardized  model.  The  Army 
named  this  model  the  AlCDM. 

2.2  Central  Entities  of  the  AlCDM 

The  AlCDM  models  the  battlefield  using  an  Entity-Relationship  (ER)  model.  It  eontains 
377  entities.  Ten  of  these  are  eonsidered  the  key  battlefield  entities  of  the  model,  in  that 
they  model  things  most  immediately  reeognizable  and  neeessary  to  C4  operations: 
FEATURE,  FACILITY,  MATERIEL,  ORGANIZATION  and  PERSON  and  their  eorresponding  types 
FACILITY -TYPE,  ORGANIZATION-TYPE,  ete.  These  battlefield  entities  are  defined  as  follows 
in  the  AlCDM  and  the  DDA: 

•  FEATURE :  A  set  of  eharaeteristies,  struetures,  or  other  entities  that  are  of  military 
signifioanee. 
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•  FACILITY:  Real  property,  having  a  speeified  use,  that  is  built  or  maintained  by 
people. 

•  MATE  RIEL:  An  objeet  of  interest  that  is  non-human,  mobile,  and  physieal. 

•  ORGANIZATION:  An  administrative  strueture  with  a  mission. 

•  PERSON:  Ahuman  being. 

The  idea  behind  this  approaeh  is  that  for  eaeh  of  the  first  five  key  entities,  there  is  an  as- 
soeiated  entity  that  deseribes  the  elass  of  the  key  entity.  For  example,  there  is  an  entity 
PERSON -TYPE  assoeiated  with  PERSON  via  an  “is  the  type  for”  relationship.  Where 
PERSON  models  an  individual,  PERSON -TYPE  models  eharaeteristies  of  a  elass  of  persons, 
sueh  as  the  rank  of  military  personnel. 

The  AICDM  also  permits  the  speeifieation  of  objeetives,  aetivities,  goals,  ete.,  and  uses 
either  the  instanees  of  the  key  entities  or  of  their  types  to  aoeomplish  these  funetions,  e.g., 
PLAN,  SITUATION,  TASK,  TARGET,  GUIDANCE.  Many  of  the  basie  relationships  between  these 
aetivity  related  entities  and  the  battlefield  objeet  types  and  objeet  items  are  illustrated  by 
the  IDEFIX  diagram  sehema  in  Figure  2. 


The  individual  relationships  among  the  battlefield  entities  (FACILITY,  FEATURE,  MATERIEL, 
ORGANIZATION,  and  PERSON)  and  their  types  are  sehematized  to  simplify  the  diagram  (in 
other  words.  Object  Types,  Object  Items,  ESTABLISHMENT,  HOLDING-ESTIMATE,  and 
ASSOCIATION  are  notional).  The  more  speeifie  relationships  between  these  entities  whieh 
are  relevant  to  our  analysis  appear  in  a  series  of  IDEFIX  diagrams  in  Appendix  A.  All  of 
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Figure  2.  AICDM  Core  Relationships 
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these  diagrams  suppress  the  display  of  the  attributes  of  AICDM  entities  to  promote  eom- 
prehension  of  the  entity  relationships.  For  details  of  the  attributes  and  their  metadata,  see 
the  full  AICDM  model,  or  the  DD  A. 

2.3  Objectives  of  the  AICDM 

One  of  the  main  goals  in  ereating  the  AICDM  was  to  use  it  as  a  vehiele  for  bringing 
within  the  DoD  standardization  proeess  all  the  new  data  requirements  identified  in  the 
JCDB.  Arguably,  JCDB’s  intended  widespread  use  in  the  C4I  eommunity  eould  be 
viewed  as  a  de  faeto  data  standard  for  information  exehange  among  the  eommunity’s 
members.  The  problem  with  this  is  other  funetional  areas  that  at  present  neither  internet 
with  C4I  systems  nor  use  the  JCDB  as  their  referenee  model  for  information  exehange. 
These  funetional  areas  may  develop  duplieative  data  struetures  on  their  own  that  will 
later  neeessitate  translators  to  interfaee  with  present  and  future  C4I  systems,  thereby  de¬ 
feating  the  overarehing  goal  of  the  DoD  data  standardization  program.  As  DISA  moves  to 
a  faster  and  more  responsive  way  of  reviewing  and  approving  the  proposed  ehanges  to 
JCDB,  it  is  likely  that  implementers  using  the  JCDB  will  feel  more  eomfortable  with  the 
idea  of  making  the  submittal  of  their  new  data  struetures  an  integral  part  of  their  work.  At 
present  the  Army  eontinues  to  endorse  the  need  for  using  the  DoD  8320  proeess  as  the 
way  to  aehieve  data  interoperability  in  all  its  information  systems. 

The  AICDM  is  meant  to  be  a  superset  of  the  C2CDM.  It  ineorporates  data  requirements 
identified  in  the  various  versions  of  the  Generie  Hub,  as  well  as  in  other  data  models  sueh 
as  the  Modernized  Intelligenee  Database  (MIDB). 

The  struetures  that  eonstitute  the  AICDM  are  to  beeome  part  of  the  DDA.  They  are  ere- 
ated  and  approved  in  full  eomplianee  with  the  DoD  8320  proeedures. 

The  AICDM  is  meant  to  be  a  logieal  data  model.  Its  purpose  is  to  eapture  data  require¬ 
ments  and  speeify  them  to  a  suffieient  level  of  detail  to  enable  funetional  experts  to  assess 
the  appropriateness  of  the  proposed  struetures.  Implementers  remain  free  to  adapt  the 
model  for  its  various  physieal  implementations. 

The  AICDM  eonstitutes  a  target  model,  and  as  sueh  is  meant  to  remain  flexible  and  eon- 
tinue  evolving.  One  of  the  advantages  of  maintaining  the  AICDM  (as  opposed  to  adopt¬ 
ing  the  JCDB)  as  the  data  model  for  information  exehange  is  that  the  AICDM  work  is  not 
eonstrained  by  any  delivery  sehedules.  Additionally,  beeause  the  struetures  of  the 
AICDM  are  submitted  to  the  DoD  8320.I-M-I  approval  proeess  (see  Seetion2.4),  they 
reeeive  inputs  from  all  the  relevant  funetional  areas.  The  struetures  of  the  JCDB  are  only 
reviewed  by  those  organizations  whieh  either  use  one  of  the  eurrent  ABCS  systems  or 
have  some  need  to  exehange  data  with  them.  Funetional  areas  outside  of  this  eommunity 
do  not  neeessarily  have  visibility  into  the  proeess  and  may  not  be  aware  of  the  solutions 
generated  there.  As  a  result  they  may  neither  be  able  nor  inelined  to  adopt  them  and  quite 
likely  will  generate  their  own,  ereating  a  potential  for  diseonneets  between  their  systems 
and  those  using  the  JCDB.  The  AICDM  therefore  provides  a  vehiele  to  avoid  ereating  yet 
another  Army  stovepipe  system,  however  broad  this  stovepipe  may  be,  so  that  other  Ser¬ 
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vices  may  take  advantage  of  the  work  done  within  the  Army,  and  thereby  reduce  the  risk 
of  decreased  data  interoperability. 

2.4  TheAlCDM  and  DoD  8320 

From  the  beginning,  DoD  has  conducted  data  standardization  efforts  in  accordance  with 
DoD-8320.1-M-l  [DoD  1998]  guidelines.  According  to  DoD-8320.1-M-l,  every  entity 
and  its  attributes  must  be  modeled  using  the  IDEFIX  methodology  [NIST  1993].  Fur¬ 
thermore,  DoD-8320.1-M-l  prescribes  a  set  of  metadata  items  required  for  every  entity 
and  attribute.  Several  of  the  metadata  items  were  particularly  important  in  the  alignment 
analysis.  Table  1,  condensed  from  [DoD  1998],  shows  these  items. 


Table  1.  DoD-8320.1-M-l  Metadata  Items  Used  in  Alignment  Analysis 


Name 

Definition 

Entity 

Metadata 

Entity  Name 

The  label  of  an  entity;  must  be  a  noun  or  noun  phrase  with 
the  entire  phrase  connected  by  hyphens;  must  accurately 
reflect  the  characteristics  (attributes)  of  itself,  especially  its 
domain. 

Definition  Text 

The  narrative  description  of  what  an  entity  is. 

Attribute 

Metadata 

Standard  Data 
Element  Name 

The  label  of  an  attribute,  comprised  of  a  minimum  of  an  en¬ 
tity  and  generic  element;  may  contain  property  modifier(s) 
providing  additional  descriptions;  may  utilize  generic  data; 
must  be  a  noun  or  noun  phrase  and  accurately  reflect  the 
characteristics  (meta-data)  of  the  attribute,  especially  do¬ 

mains. 

Data  Type  Name 

The  name  of  the  way  domai  n  val  ues  are  stored  i  n  a  data¬ 
base.  The  generic  data  elements  with  dass  words  having  a 
data  type  of  "integer"  will  be  modified  with  a  comment 
(comment  text  field)  as  follows:  Data  element  using  the  data 
type  "integer"  should  fit  into  a  32  bit  representation.  The 
high  range  value  of  a  signed  integer  is  limited  to  "2.1  billion" 
(in  the  range -23i  to  23i-l);  data  requirements  of  greater  val¬ 
ues  should  use  the  data  types  "floating  point"  or  "fixed 
point". 

Domain  Value 
Identifier 

The  actual  codes  that  provide  access  to  1  ists  of  categories  of 
objects. 

One  of  the  requirements  of  the  DoD-8320.1-M-l  process  is  that  the  data  structures  mod¬ 
eled  using  the  IDEFIX  methodology  be  in  “third  normal  form”.  Third  normal  form  in¬ 
volves  the  separation  of  data  into  bins  that  provide  a  “tight  fit”  to  the  data  needed  to  be 
captured  in  the  tables  of  a  relational  database.  The  downside  of  this  is  the  proliferation  of 
entities,  and  later  on  tables  in  the  physical  data  base,  which  may  require  the  DBMS  to 
search  in  various  tables,  rather  than  a  single  one.  Some  DBMSs  experience  large  per¬ 
formance  degradation  when  the  number  of  tables  that  need  to  be  searched  to  extract  the 
data  becomes  large.  During  physical  implementation  many  of  these  tables  are  routinely 
combined  into  a  single  one  and  validation  rules  are  implemented  to  ensure  that  data 
which  at  the  logical  level  was  depicted  as  a  separate  entity,  and  would  have  been  in  a 
separate  table  of  the  relational  database,  is  placed  in  the  appropriate  portions  of  the  “de- 
normalized”  table.  With  ever-increasing  CPU  speeds  and  overall  better  DBMS  perform¬ 
ance,  the  need  to  use  this  approach  when  generating  the  physical  schema  out  of  a  logical 
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data  model  may  become  less  necessary,  and  the  logical  and  physical  schemas  of  the  C4I 
systems  may  remain  fairly  close  to  each  other 

2.5  Current  Status  of  the  AlC DM 

As  indicated  above,  the  AICDM  is  a  plaimed  expansion  of  current  DoD  C2  data  model 
specifications  in  support  of  newly  identified  data  requirements.  The  AICDM  is  an  out¬ 
growth  of  DoD’s  C2  Core  Data  Model  (C2CDM),  with  important  influences  from  the 
fourth  version  of  the  Generic  Hub  data  model  (GH4)  and  the  Joint  Common  Database 
(JCDB).  Begun  in  1997,  AICDM  is  an  ongoing  effort  that  will  support  force-level  C2, 
including  a  common  picture  of  the  battlefield,  information  exchange  (both  pushed  and 
pulled),  and  distributed  collaborative  plarming,  as  well  as  integration  with  all  the  other 
functional  areas,  such  as  Intelligence,  Air  Operations,  and  Naval  Warfare.  AICDM  is  the 
Army’s  target  model  for  tactical  databases. 

The  AICDM  is  defined  using  entity-relationship  (ER)  modeling  concepts.  Because  of 
limitations  imposed  by  DISA,  as  well  as  the  manpower  available  to  generate  the  data 
proposal  packages,  the  data  structures  of  the  AICDM  become  part  of  the  DoD  standard  in 
finite  increments.  The  portions  of  the  AICDM  that  have  gone  through  the  DoD-8320.I- 
M-I  process  and  reached  approval  status  are  captured  in  so-called  “views”,  i.e.,  extracts 
from  the  totality  of  the  model^  Each  view  depicts  a  facet  of  a  battlefield  C4I  model;  the 
union  of  all  the  views  is  the  complete  AICDM  model.  Table  2  lists  some  of  the  approved 
AICDM  views.  Appendix  C  lists  the  complete  set  of  the  AICDM  views  and  their  status  as 
of  this  time.  These  views  give  a  flavor  of  the  AICDM ’s  intent:  to  model  battlefield  ob¬ 
jects.  The  AICDM  attempts  to  model  anything  that  might  be  relevant  to  the  warfighter. 
Personnel,  materiel,  organizations,  terrain,  and  facilities  are  all  within  its  purview. 


Table  2.  Selected  AICDM  Views  and  Their  Purposes 


View 

Purpose 

ACTION 

A  model  of  how  an  organization  may  describe  the  actions  it  undertakes, 
the  objectives  of  those  actions,  and  the  resources  needed  to  perform 
them. 

CAPABILITY 

A  model  of  the  expected  and  actual  capabilities  of  a  person,  organization, 
or  feature 

Feature  View 

A  model  of  something— physical  or  logical— that  isof  military  signifi¬ 
cance. 

ORGANIZA¬ 

TION 

A  model  of  administrative  structures,  with  specific  missions  and  their 
relationships. 

Plan  View 

A  model  of  how  to  achieve  some  objective  over  time. 

It  is  important  to  understand  that  there  is  nothing  special  about  the  views.  The  full  model 
is  the  ultimate  definition  of  the  AICDM.  The  views  are  derived  from  the  full  model.  The 
set  of  views  that  the  AICDM  contained  when  the  IDA  team  examined  it  initially  for  the 
purpose  of  this  analysis  had  been  created  to  support  the  data  proposal  packages  being 
submitted  to  DISA  by  the  Army  Data  Management  Group  at  Ft.  Belvoir  to  standardize 
the  entities  and  attributes  contained  therein.  In  some  cases  the  existing  views  constituted 


*  The  Army  maintains  the  AICDM  views  and  specifications  at  the  Army  Operational  Data  Repository 
website,  the  URL  of  which  is  http  ://aodr-arch-odisc4 . army. mil/. 
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excellent  points  of  departure  for  the  alignment  analysis  study.  In  other  cases  the  IDA 
team  had  to  create  new  ones  from  the  pool  of  all  AICDM  entities  to  capture  the  corre¬ 
sponding  classes  of  the  OMSC.  Such  cases  are  noted  in  the  text. 

It  is  also  important  to  understand  that  this  report  uses  the  term  “view”  casually.  Techni¬ 
cally,  a  view  includes  all  the  entities  connected  to  those  one  would  like  to  think  of  as 
making  up  the  view.  This  is  needed  to  ensure  that  no  foreign  keys  appear  in  any  of  the 
tables  without  their  parent  entities  being  properly  defined  in  the  model.  For  instance,  the 
AICDM’s  ORGANIZATION  view  contains  an  entity  ORGANIZATION-FACILITY,  which  has 
an  attribute  FACILITY  IDENTIFIER;  yet  the  ORGANIZATION  view  does  not  include  the 
FACILITY  entity.  According  to  the  usual  formal  definition  of  a  view,  the  ORGANIZATION 
view  lacks  referential  completeness.  However,  a  view  with  referential  completeness  quite 
often  includes  tens  of  entities  that  add  little  actual  information.  Data  modelers  customar¬ 
ily  omit  entities  from  a  view  that  are  not  related  to  those  relevant  to  the  subject  of  the 
view  either  directly  (i.e.,  they  have  either  identifying  or  non-identifying  relationships  to 
the  relevant  entities  in  question),  or  form  part  of  an  associative  pair  with  the  focal  entity 
of  the  view  (e.g.,  FACILITY  is  excluded  from  the  ORGANIZATION  view  even  though  the 
ORGANIZATION  view  includes  the  entity  ORGANIZATION-FACILITY,  which  is  a  child  of 
FACILITY). 

2.6  AICDM  Conventions 

The  AICDM  has  some  conventions  that  bear  mention.  Knowledge  of  these  conventions  is 
necessary  to  understand  certain  material  in  this  report.  Some  of  these  conventions  are 
commonly  used  throughout  the  data  modeling  community.  Others  are  specific  to  the 
AICDM  in  that  they  reflect  specifics  of  the  DoD  8320  guidelines. 

2.6.1  Naming  Conventions 

AICDM  entities  and  attributes  follow  simple  and  useful  naming  conventions.  An  entity’s 
name  is  in  upper  case.  If  it  is  composed  of  multiple  words,  those  words  are  separated  by 
hyphens.  PERSON  and  MATERIEL-ITEM  are  examples  of  entity  names. 

The  attribute’s  name  includes  the  name  of  its  entity  as  a  prefix.  The  entity  PERSON  has 
attributes  PERSON  IDENTIFIER,  PERSON  BIRTFI  DATE,  etc.  The  attributes  of  the  entity 
MATERIEL-ITEM  include  MATERIEL-ITEM  NAME  and  MATERIEL-ITEM  TYPE  CODE.  Note  also  the 
space  between  the  entity  name  and  the  remainder  of  the  attribute’s  name.  This  convention 
lets  the  reader  determine  an  attribute’s  entity  from  the  attribute’s  name.  It  also  promotes 
brevity,  since  one  can  write  “PERSON  BIRTFI  DATE”  rather  than  “the  BIRTFI  DATE  attribute  of 
the  PERSON  entity”  without  being  ambiguous. 

Because  the  AICDM  uses  the  IDEFIX  methodology,  a  child  entity  inherits  the  key  attrib¬ 
utes  of  its  parent  entities;  as  a  result,  an  AICDM  entity  such  as  PERSON  may  show  an  at¬ 
tribute  named  RACE  CODE,  coming  from  the  entity  RACE.  In  such  cases,  this  report  explic¬ 
itly  identifies  the  entity  with  which  the  attribute  is  associated. 
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2.6.2  Modeling  Many-to-Many  Relationships 

Usually,  a  relationship  in  an  ER  model  ean  be  implemented  in  a  relational  database  by  the 
straightforward  means  of  expressing  it  as  a  single  relation,  with  eaeh  of  the  key  attributes 
of  the  parent  entity  being  inherited  by  the  ehild  entity.  If  two  entities  have  a  many-to- 
many  relationship  (eonsider  PERSON  and  ORGANIZATION),  the  usual  teehnique  to  imple¬ 
ment  that  relationship  is  to  ereate  an  intermediate  assoeiative  entity  that  is  the  ehild  of 
both  entities  related  by  the  many-to-many  relationship.  This  assoeiative  entity: 

•  Contains  as  attributes  the  keys  of  both  the  entities  it  relates.  For  example,  the 
assoeiative  entity  implementing  the  relationship  between  PERSON  and 
ORGANIZATION,  namely  PERSON-ORGANIZATION,  eontains  ORGANIZATION 
IDENTIFIER  and  PERSON  IDENTIFIER. 

•  May  eontain  attributes  of  its  own  that  partieipate  in  the  key,  to  permit  the  asso- 
eiation  of  the  same  pair  of  instanees  of  the  key  attributes  from  the  parent  enti¬ 
ties  if  the  role  of  the  assoeiation  is  different  or  refleets  the  history  of  the  possi¬ 
ble  values.  For  example,  a  person  may  serve  in  a  unit  at  one  time,  leave  for  a 
eouple  of  years,  then  eome  baek  to  the  same  unit  and  serve  again.  Thus  the  as¬ 
soeiative  entity  PERSON-ORGANIZATION  eontains  attributes  to  reeord  the  time  a 
person  begins  eaeh  assoeiation  with  an  organization. 

•  May  eontain  non-key  attributes  of  its  own.  For  example,  a  person  is  assoeiated 
with  an  organization  for  a  defined  time  period.  Thus  the  assoeiative  entity 
PERSON-ORGANIZATION  eontains  attributes  to  reeord  the  time  a  person  ends  an 
assoeiation  with  an  organization. 

In  the  AICDM  all  many-to-many  relationships  are  resolved  via  assoeiative  entities.  See 
Figure  3. 

The  AICDM  names  the  intermediate  entity  by  eombining  the  names  of  the  two  entities 
from  the  many-to-many  relationship.  It  therefore  has  an  entity  PERSON-ORGANIZATION. 
The  attributes  of  PERSON-ORGANIZATION  follow  the  naming  eonventions  in  Seetion  2.6.1. 

2.7  I  nstances.  Types,  and  Quantities 

When  modeling  one’s  own  forees,  it  is  advantageous  to  note  individual  persons  and  mate¬ 
riel  insofar  as  is  possible.  In  other  words,  the  model  should  be  eapable  of  reeording  the 
names  of  all  individuals  in  an  organization  and  the  serial  numbers  of  all  equipment  the 
organization  possesses. 


Figure  3.  AICDM  Representation  of  Many-to-Many  Relationship 
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But  organizations  are  not  in  the  habit  of  deseribing  their  strength  to  their  foes,  so  it  is  un- 
realistie  to  expeet  a  data  model  to  eontain  the  names  and  weaponry  of  one’s  opponents. 
An  organization  ean  expeet  to  reeeive  intelligenee  on  tidbits  like  approximate  strength,  at 
least  as  a  raw  number  (“three  armored  battalions”),  and  a  data  model  must  eapture  it.  The 
AICDM  addresses  this  area  by  providing  entities  that  model  types  rather  than  instanees. 
Examples  inelude: 

•  PERSON-TYPE,  to  model  different  eategories  of  individuals  (military  vs.  non¬ 
military;  if  military,  the  rank). 

•  ORGANIZATION-TYPE,  to  model  different  types  of  organizations  (military  vs.  non¬ 
military;  if  military,  the  serviee,  and  distinguishing  eharaeteristies  sueh  as  head¬ 
quarters,  vanguard,  and  rear  guard). 

•  MATERIEL-ITEM,  to  model  different  types  of  materiel.  The  AICDM  ineludes  sub- 
types  of  MATERIEL-ITEM  for  eommon  (and  often  eomplex)  types  of  materiel,  in¬ 
eluding  WEAPON-TYPE  and  VEHICLE-TYPE). 

The  AICDM  relates  these  entities  to  organizations,  personnel,  faeilities,  materiel,  and  fea¬ 
tures  in  one-to-many  relationships  that  use  an  appropriate  “holding”  entity  as  an  interme¬ 
diate  (See  Figure  4).  A  holding  entity  deseribes  the  quantity  of  some  entity  type  that  an 
instanee  of  an  entity  possesses.  For  example: 

•  The  MATERIEL-ITEM-PERSON-HOLDING-ESTIMATE  entity  models  an  estimate  of 
how  many  instanees  of  a  MATERIEL-ITEM  a  PERSON  possesses.  The  attributes  of 
the  entity  inelude  not  only  the  quantity  but  a  statement  of  the  estimate’s  aeeu- 
raey. 

•  The  PERSON-TYPE-ORGANIZATION-HOLDING-ESTIMATE  entity  models  an  estimate 
of  the  number  of  people  of  a  given  type  in  a  given  organization. 
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Figure  4.  Examples  of  AlCDM  "HOLDING"  Entities 
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3.  Overview  of  the  OMSC 


The  Object  Management  Standards  Category  (OMSC)  was  formed  in  April  1997  to  de¬ 
velop  standard  objects  for  Army  M&S  functions.  The  OMSC  is  organized  and  maintained 
by  the  US  Army  Materiel  Systems  Analysis  Activity  (AMSAA).  Its  objective  is  to  unify 
the  many  competing  object  models  developed  by  Army  and  Joint  offices.  The  intent  is  to 
provide  “a  high-level  object  class  structure  independent  of  any  specific  simulation  envi¬ 
ronment.”  [AMSAA]  The  OMSC  aims  to  give  future  M&S  projects  products  that  guide 
M&S  architecture,  design,  and  implementation  through  standards  and  software  reuse. 

3.1  OMSC  Organization  and  Structure 

The  OMSC  work  products  comprise  a  set  of  standard  objects.  Each  standard  object 
represents  a  recognizable  concept  commonly  used  in  M&S  systems.  Standard  objects  ex¬ 
tant  at  this  time  (in  varying  stages  of  completeness)  include: 

•  Platform:  A  platform  is  any  item  that  can  be  treated  as  an  entity.  Vehicles  are 
examples  of  platforms.  So  are  subcomponents  of  vehicles;  that  is,  a  platform  is 
composed  of  platforms.  An  individual  human  is  another  example  of  a  platform. 

•  Unit:  A  Unit  is  a  military  organization  that  represents  a  collection  of  entities. 
Units  encompass  organizations  (companies,  battalions,  brigades,  etc.)  and  func¬ 
tional  groups  (e.g.,  fire  control  centers). 

•  Location:  A  Location  models  information  about  the  location  of  some  entity  or 
collection  of  entities. 

•  Behavior:  A  Behavior  object  provides  a  framework  that  encapsulates  the  defini¬ 
tion  of  behavior  within  an  M&S  system. 

Each  standard  object  consists  of  a  set  of  associated  classes.  In  object-oriented  software 
development,  a  class  serves  as  a  template  for  a  set  of  object  instances.  Each  instance 
models  to  an  object,  either  a  real-world  physical  object  (e.g.,  a  weapon),  a  real-world 
conceptual  object  (e.g.,  an  organization),  or  a  conceptual  object  defined  during  software 
development  (e.g.,  a  stack).  OMSC  classes  model  only  real-world  objects. 

In  standard  objects  defined  so  far,  one  of  these  classes  bears  the  same  name  as  the  stan¬ 
dard  object,  and  can  be  considered  as  most  intuitively  representing  the  concept  that  the 
standard  object  models,  capturing  the  central  point  of  the  standard  object.  It  is  the  class 
that  would  be  instantiated  to  represent  an  object  instance.  We  term  this  class  the  focal 
class. 

The  focal  class  has  associations  with  other  classes  in  the  standard  object.  Some  of  these 
classes  in  turn  have  associations  with  other  classes.  (The  upshot  is  that  the  focal  class  has 
a  transitive  association  to  all  classes  in  a  standard  object.)  The  OMSC  uses  two  types  of 
associations: 
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1.  Aggregation:  The  OMSC  uses  this  assoeiation  to  eapture  a  situation  where  an  in- 
stanee  of  one  elass  is  assoeiated  with  several  instanees  of  an  other  elass.  For  example, 
a  Unit  may  have  several  Communieations  eapabilities. 

2.  Inheritanee:  The  OMSC  uses  inheritanee  to  eapture  subtyping  relationships.  For  ex¬ 
ample,  the  OMSC  defines  Maintenanee  as  a  type  of  Logisties. 


Figure  5.  The  OMSC  Unit  Standard  Object 


Figure  6.  The  OMSC  Platform  Standard  Object 


Figure?.  The  OMSC  Location  Standard  Object 
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The  class  diagrams  for  the  completed  OMSC  standard  objects — ^Unit,  Platform,  and  Lo¬ 
cation — are  presented  in  Figure  5,  Figure  6,  and  Figure  7.  These  figures,  which  are  taken 
from  OMSC  specifications,  use  the  Unified  Modeling  Language  (UML)  [Booch  1996].  In 
UML,  a  class  is  represented  by  a  rectangle.  Associations  between  two  classes  are  shown 
by  connecting  them  with  lines.  If  the  line  has  a  diamond,  the  class  touching  the  diamond 
may  have  zero  or  more  instances  of  the  class  at  the  other  end  of  the  line.  If  the  line  has  a 
triangle,  the  class  touching  the  triangle  is  a  superclass  of  the  class  at  the  other  end  of  the 
line. 

The  OMSC  describes  a  class  using  three  characteristics: 

1 .  A  class  has  a  name.  This  name  is  suggestive  of  the  role  of  the  class. 

2.  A  class  has  a  prose  description.  (“Prose”  means  that  automated  analysis  is  impracti¬ 
cal.  Human  analysis  may  suggest  alignment  strategies,  but  they  can  never  be  guaran¬ 
teed.  Prose  can  be  aligned  only  to  other  prose.)  It  adds  detail,  and  sometimes  exam¬ 
ples,  to  the  name. 

3.  A  class  has  a  set  of  methods.  In  object-oriented  programming,  the  methods  of  a  class 
define  the  legal  set  of  operations  that  may  be  performed  on  instances  of  a  class.  These 
operations  govern  exactly  how  instances  may  change  over  time,  and  what  properties 
of  an  instance  may  be  viewed  at  any  time.  The  OMSC  uses  methods  of  both  types. 
For  example,  the  Unit  object  includes  the  following  two  methods: 

1 .  getLocationO,  which  yields  the  unit’s  current  location. 

2.  moved,  which  moves  the  object  to  a  specified  location. 

The  OMSC  describes  a  method  using  a  name  and  a  (prose)  description. 

3.2  OMSC  Status,  Directions,  and  Issues 

The  OMSC  standard  objects  are  not,  in  their  current  state,  complete  models.  Its  creators 
have  envisioned  many  standard  objects  but  defined  few.  Initial  plans  called  for  six  stan¬ 
dard  objects  (Unit,  Platform,  Location,  Environment,  Data,  and  Behavior)  by  the  end  of 
2000.  Only  Unit,  Platform,  and  Location  were  completed.  There  are  plans  to  add  more 
standard  objects  to  this  set,  but  the  objects  have  not  been  agreed  upon  and  no  schedule 
has  been  established.  The  Army  recognizes  that  simulation  encompasses  much  more  than 
the  OMSC  currently  describes. 

The  standard  objects  that  have  been  defined  are  deliberately  vague.  The  OMSC’s  charter 
is  to  create  abstract  objects  that  are  simulation- independent,  so  its  members  do  not  want 
to  constrain  standard  objects  by  tying  them  to  a  specific  simulation  environment.  They 
chose  to  incorporate  as  many  simulation  systems  as  possible  into  their  model.  The  classes 
in  the  OMSC  provide  high-level  architectural  guidance  for  a  very  broad  range  of  M&S 
systems. 

The  OMSC  provides  little  guidance  below  the  architectural  level,  however.  The  many 
sources  drawn  on  to  define  the  OMSC  standard  objects  have  disparate  implementations, 
and  incorporating  them  into  one  model  creates  conflicts.  Consider,  for  example,  how  to 
specify  the  operation  of  moving  a  unit.  Does  one  state  the  final  destination,  or  provide  a 
direction  of  motion  relative  to  the  current  location?  Is  the  direction  relative  to  the  Earth’s 
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geodetic  coordinates,  or  to  the  unit’s  current  orientation?  And  to  what  precision  must  a 
location  be  described?  Different  M&S  systems  answer  each  of  these  questions  in  their 
own  way. 

The  OMSC’s  members  decided  to  omit  the  detailed  information  that  would  make  these 
conflicts  surface.  The  information  omitted  includes  the  following: 

•  Method  return  values.  There  is  no  explicit  and  uniform  indication  of  whether  a 
method  returns  a  value.  Sometimes  the  method’s  description  alludes  to  a  re¬ 
turned  value  (for  instance,  getLocationO  returns  the  current  unit  location).  But  the 
description  usually  does  not  state  with  any  exactness  the  return  value’s  seman¬ 
tics. 

•  Parameters  for  methods.  The  OMSC  specifications  never  state  the  parameters 
required  for  methods.  This  leaves  open  many  possible  interpretations  for  state¬ 
modifying  methods.  For  example,  the  description  of  the  Unit’s  move()  method 
says  that  it  advances  a  unit  toward  its  next  location.  It  does  not  say  how  that  lo¬ 
cation  is  determined,  which  is  information  that  parameters  would  supply. 

•  Descriptions  of  data  types.  Many  possible  data  types  can  be  inferred  from  de¬ 
scriptions  of  classes  or  methods,  but  the  OMSC  does  not  give  details  on  any  of 
them.  For  example,  the  Geocentric  class,  which  is  a  subclass  of  Location,  has  a 
method  getLatitudeO,  which  returns  a  latitude.  The  precision  of  this  latitude  is  not 
stated. 

But  omitting  details  spells  trouble  for  alignment  efforts.  We  might  perform  a  superficial 
analysis  of  movement  in  the  two  models  and  decide  that  they  are  aligned:  after  all,  both 
the  AICDM  and  the  OMSC  standard  objects  model  location.  But  when  we  start  examin¬ 
ing  details  of  movement,  we  find  questions  about  the  OMSC  standard  objects  we  cannot 
answer.  Determining  the  degree  to  which  two  models  are  aligned  is  a  matter  of  examining 
details.  Details,  unfortunately,  are  exactly  what  OMSC  standard  objects  lack. 

We  address  this  problem  by  defining  a  model  with  four  different  levels  of  alignment.  We 
use  these  levels  to  show  what  we  might  determine  if  the  OMSC  standard  objects  were 
more  complete  (covering  all  four  levels),  and  then  discuss  what  we  can  determine  based 
on  the  OMSC’s  current  state;  the  gap  between  “might”  and  “can”  is,  we  shall  see,  consid¬ 
erable. 
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4.  Definition  of  Alignment 


This  section  describes  in  depth  the  meaning  of  alignment  between  the  OMSC^  and  the 
AICDM.  As  will  soon  be  explained,  alignment  can  mean  several  things,  depending  on 
which  elements  one  selects  from  the  models  being  aligned.  This  section  defines  define 
four  possible  meanings,  and  chooses  one  as  the  focus  of  the  analysis  in  this  report. 

The  definition  was  created  for  studying  alignment  of  the  AICDM  and  the  OMSC.  It 
serves  well  as  a  definition  of  alignment  between  an  ER  model  and  an  00  model  that  uses 
the  modeling  constructs  of  the  OMSC  (see  Section  3.1).  However,  the  OMSC  makes  lim¬ 
ited  use  of  00  modeling  capabilities  (see  Appendix  B).  Without  modification,  the  defini¬ 
tion  may  not  be  optimal  for  studying  alignment  to  other  00  models. 

Alignment  is  used  to  determine  whether  AICDM  elements  (views,  entities,  relationships, 
attributes,  and  domains)  align  with  OMSC  elements  (standard  objects,  classes,  and  meth¬ 
ods),  and  vice  versa.  What,  then,  does  it  mean  to  say  elements  are  or  are  not  aligned? 

What  alignment  means  depends  upon  the  modeling  elements  used.  The  AICDM  is  an  ER 
model.  The  OMSC  standard  objects  use  00  modeling.  We  can  consider  aligning  entities 
in  an  ER  model  to  classes  in  an  object  model;  this  is  concerned  (roughly)  with  matching 
things  that  model  the  same  types  of  physical  objects.  Or  we  can  consider  aligning  attrib¬ 
ute  domains  in  an  ER  model  to  data  types  in  an  object  model.  This  is  a  set  intersection 
issue. 

The  more  formal  the  modeling  elements,  the  more  rigorous  the  definition  of  alignment. 
Set  theory  can  be  used  to  determine,  rigorously,  if  an  attribute  domain  and  a  data  type  are 
aligned.  Their  union  must  equal  their  intersection.  But  what  does  it  mean  to  say  an  entity 
is  aligned  with  a  class?  The  informal  definition  above,  about  representing  the  same 
physical  objects,  still  leaves  room  for  interpretation. 

We  can  think  of  a  spectrum  of  alignment  rigor.  The  top,  highly  abstract  level  comprises 
real-world  concepts.  At  this  level,  we  consider  alignment  intuitively.  The  bottom,  highly 
detailed  level  has  mathematical  rigor  suited  to  formal  reasoning  and  computer-based  im¬ 
plementations.  In  between  are  levels  of  increasing  formality. 

We  identify  four  levels  of  alignment:  Conceptual  (level  1),  Entity  (level  2),  State  (level 
3),  and  Value  (level  4).  They  are  summarized  in  Table  3.  The  rest  of  this  section  describes 
each  level  and  defines  what  alignment  between  the  AICDM  and  the  OMSC  means  at  that 
level.  When  we  speak  of  alignment,  we  always  refer  to  a  particular  level. 


^  In  the  remainder  of  this  doeument  ,“OMSC”  is  sometimes  used  as  a  shorthand  for  “OMSC  standard 
objeet(s)”. 
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There  is  a  pattern  to  the  levels.  In  levels  1-3,  level  i  eontains  a  set  of  names  of  entities 
that  are  the  foeus  of  level  i+1.  In  level  1,  an  OMSC  standard  objeet  ineludes  a  set  of  elass 
names;  elasses  are  the  foeus  of  level  2  in  the  OMSC.  At  level  2,  an  AICDM  entity  eon- 
tains  attribute  names;  attributes  are  the  foeus  of  level  3  in  the  AICDM. 

Diseussion  of  eaeh  level  is  broken  into  four  parts: 

1 .  Definition  of  level:  An  intuitive  statement  of  the  types  of  entities  that  make  up  the 
level. 

2.  Interpretation  in  the  AICDM:  The  elements  of  the  AICDM  that  appear  in  the  level. 

3.  Interpretation  in  the  OMSC:  The  elements  of  the  OMSC  that  appear  in  the  level. 

4.  Meaning  of  alignment:  What  it  means  to  say  that  the  AICDM  and  the  OMSC  are 
aligned  with  respeet  to  the  level. 

Table  3.  The  Four  Levels  of  Alignment 


Level 

Participating  Model  Entities 

OMSC 

AICDM 

1  Conceptual: 
Entities  of 
user  percep¬ 
tion 

Standard  Object 

•  Name 

•  Set  of  class  names 

•  Focal  class  name 

•  Associations 

View 

•  Name 

•  Set  of  entity  names 

•  Focal  entity  name 

•  Relationships 

2  Entity:  Enti¬ 
ties  of  data 
model 

Class 

•  Name 

•  Description 

•  Set  of  method  names 

Entity 

•  Name 

•  Description 

•  Set  of  attribute  names 

3  State:  De¬ 
scriptions  of 
entity  state 

Method 

•  Name 

•  Description 

•  If  method  is  behavioral: 

•  Set  of  parameters:  name  and  data  type 
(implicit  in  the  OMSC) 

•  Optional  return  value  data  type 
(implicit  in  the  OMSC) 

•  If  method  is  non-behavioral: 

•  Return  value  data  type 

Attribute 

•  Name 

•  Description 

•  Domain  name 

4  Value:  De¬ 
scriptions  of 
domains 

Data  T  ype 

•  Name 

•  Set  of  values  (discrete  or  continuous) 

•  Relations: 

•  Comparison 

•  Order 

Attribute  Domain 

•  Name 

•  Set  of  values  (discrete  or 
continuous) 

So  far  alignment  has  been  presented  as  blaek  and  white:  entities  are,  or  are  not  aligned.  In 
faet  the  alignment  definition  reeognizes  shades  of  gray.  Stating  simply  that  the  AICDM 
and  the  OMSC  are  not  eurrently  aligned  is  not  useful.  We  want  to  know  how  elosely  they 
are  aligned,  and  what  steps  to  take  to  align  them  further.  For  this  reason,  the  material  on 
meaning  of  alignment  e overs  degree  of  alignment.  The  degree  of  alignment  is  a  rough 
measure  of  the  number  of  entities  that  would  need  to  be  ehanged  to  aehieve  full  align¬ 
ment  between  the  two  models. 
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How  one  interprets  degree  of  alignment  depends,  like  alignment,  on  the  level  at  which 
alignment  is  viewed.  The  intent  here  is  that  it  provide  a  quantitative  means  to  assess  how 
a  change  to  the  AICDM  or  the  OMSC  affects  alignment:  closer,  farther,  or  not  at  all.  The 
definition  given  here  yields  a  percentage.  An  AICDM  entity  and  an  OMSC  entity  might 
be  assessed  to  be  25%  in  alignment. 

Percentages  do  not  suggest  effort.  They  measure  the  number  of  entities  in  alignment,  and 
say  nothing  about  how  alignment  might  be  achieved.  Going  from  10%  to  99%  might  re¬ 
quire  less  effort  than  going  from  99%  to  100%. 

For  levels  1-3,  degree  of  alignment  is  determined  in  terms  of  entities  of  the  next  lower 
level.  Degree  of  alignment  at  the  Conceptual  level  is  determined  based  on  entities  in  the 
Entity  level;  degree  of  alignment  at  the  Entity  level  is  determined  based  on  entities  in  the 
State  level;  and  degree  of  alignment  at  the  State  level  is  determined  based  on  entities  in 
the  Value  level.  Degree  of  alignment  at  the  Value  level  has  a  self-contained  definition. 

For  levels  1-3,  degree  of  alignment  can  also  be  defined  independent  of  the  next  lower 
level.  Such  a  definition  is  necessary  if  assessments  at  the  next  lower  level  are  not  possible 
(a  situation  that  occurs  more  often  than  at  the  State  level  in  the  AICDM-OMSC  alignment 
assessment).  The  sections  on  meaning  of  alignment  discuss  how  to  deal  with  these  cases. 

4.1  Conceptual  Level 

4.1.1  Definition  of  Level 

A  concept  is  a  mental  abstraction.  The  Conceptual  level  is  concerned  with  the  highest 
level  abstractions  one  uses  when  thinking  about  a  system,  and  the  components  of  those 
abstractions.  For  instance,  when  someone  thinks  about  an  automobile,  they  think  of 
wheels,  a  chassis,  and  an  engine.  When  they  think  of  a  military  unit,  they  think  of  a  group 
of  people  and  equipment.  They  may  also  think  of  properties  of  the  system,  such  as  the 
velocity  of  an  automobile,  and  the  location  of  a  military  unit. 

The  Conceptual  level  helps  people  imagine  a  system  and  its  concept  of  operations.  They 
want  a  general  understanding  of  the  entities^  in  the  system.  They  are  satisfied  to  assign  a 
label  such  as  “vehicle”  or  “unit”  to  each  concept. 

4.1.2  Interpretation  in  AICDM 

The  AICDM  models  the  Conceptual  level  as  a  set  of  ER  entity  names,  along  with  the 
names  of  the  ER  relationships  that  associate  them,  and  an  informal  (textual)  definition  of 
intended  semantics.  In  ER  modeling,  the  usual  name  for  this  aggregate  is  a  view.  A  view 
has  a  name  that  suggests  what  it  models.  Section  2.5  covered  some  of  the  current  AICDM 
views. 

One  entity  in  a  view  is  typically  a  “focal”  entity,  its  name  suggesting  the  whole  concept. 
For  example,  the  AICDM  has  a  view  named  Organization.  This  view  contains  an  entity 


^  The  words  “entity”  and  “relationship”  are  used  here  in  their  general  sense,  not  as  is  meant  in  ER  mod¬ 
eling.  In  this  doeument,  the  meaning  of  the  words  will  be  clear  from  context,  or  explieitly  stated. 
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named  ORGANIZATION.  It  contains  other  entities  with  attributes  relevant  to  modeling  an 
organization,  such  as  ORGANIZATION-OPERATIONAL-STATUS,  COUNTRY,  and  MISSION.  From 
the  names  of  these  entities,  it  should  be  clear  that  ORGANIZATION  is  the  one  most  central  to 
the  view.  ORGANIZATION,  then,  is  the  focal  entity  of  the  Organization  view. 

It  is  important  to  understand  how  the  existing  AICDM  views  are  used  in  the  alignment 
study.  They  serve  as  points  of  departure,  not  as  abstractions  against  which  the  OMSC  is 
compared.  The  existing  AICDM  views  were  not  created  to  represent  M&S  data,  so  it 
would  be  unwise  to  expect  that  any  given  AICDM  view  should  map  exactly  to  some 
OMSC  construct.  During  the  alignment  analysis,  it  was  often  useful  to  look  at  a  prede¬ 
fined  AICDM  view  instead  of  trying  to  tackle  the  entire  AICDM  model.  However,  the 
views  defined  for  the  purposes  of  Conceptual  alignment  are  the  creations  of  this  study. 
They  are  drawn  from  the  complete  AICDM  model,  not  from  any  single  AICDM  view, 
and  they  should  not  be  taken  to  reflect  the  existing  AICDM  views. 

4.1.3  I  nterpretation  in  the  OMSC 

The  OMSC  models  the  conceptual  level  as  a  standard  object.  A  standard  object  has  a 
name,  and  consists  of  a  set  of  classes,  plus  associations  among  the  classes.  Each  class  has 
a  name  and  an  informal  (textual)  definition;  nothing  else  about  the  class  is  relevant  at  the 
Conceptual  level.  Analogous  to  the  AICDM,  one  class  is  typically  a  focal  class.  For  ex¬ 
ample,  the  OMSC  models  a  unit  as  a  standard  object  of  thirteen  classes:  Unit,  UnItGeometry, 
Intel,  Communications,  etc.  The  associations  relate  Unit  with  the  other  classes  in  the  standard 
object.  See  Figure  5. 

The  associations  serve  two  purposes: 

1 .  They  express  one  to  many  relationships.  One  unit  can  have  many  platforms,  for  ex¬ 
ample. 

2.  They  promote  reuse  of  architectural  concepts.  Both  units  and  platforms  can  have  a 
communications  capability  Rather  than  having  both  the  Unit  and  Platform  class  contain 
identical  communications  methods,  the  OMSC  defines  a  class  Communication  and  asso¬ 
ciates  it  with  both  Unit  and  Platform.  In  this  way.  Communication  is  shared  across  stan¬ 
dard  objects. 

4.1.4  Meaning  of  Alignment 

The  AICDM  and  the  OMSC  are  fully  aligned  with  respect  to  a  concept  when  both  can 
model  that  concept.  An  OMSC  concept  is  modeled  as  a  standard  object,  and  an  AICDM 
concept  as  a  view.  To  say  that  the  OMSC  and  the  AICDM  align  with  respect  to  a  concept 
is  to  say  that  all  of  the  following  statements  are  true: 

•  There  exists  an  OMSC  standard  object  whose  name  has  the  same  interpretation 
as  that  of  an  AICDM  view.  (We  are  free  to  create  views,  but  the  name  of  a  view 
should  reflect  the  elements  it  contains.) 

•  The  focal  class  of  the  standard  object  is  similar  to  the  focal  entity  in  the  view. 

•  For  each  class  in  the  standard  object,  there  exists  an  ER  entity  (or  set  of  enti¬ 
ties)  in  the  AICDM  view  that  appears  to  model  the  same  thing. 

•  For  each  aggregation  association  in  the  standard  object,  there  exists  a  relation¬ 
ship  in  the  view  that  captures  the  association  (including  cardinality).  Since 
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many  to  many  relationships  in  the  AICDM  are  implemented  using  an  interme¬ 
diate  entity,  the  aggregation  assoeiation  may  map  to  two  relationships  and  an 
entity. 

Phrases  in  these  statements — “suggests  a  similar  purpose”,  “seems  similar”,  “appears  to 
model  the  same  thing” — imply  that  Coneeptual  alignment  is  subjeetive.  The  wording  is 
deliberate.  With  only  the  Coneeptual  level  modeling  elements  (see  Table  3),  rigorous 
analysis  isn’t  possible.  In  faet,  rigorous  analysis  is  only  possible — and  not  neeessarily 
guaranteed — at  the  Data  Value  level.  All  other  levels  have  some  degree  of  subjeetivity. 
The  Coneeptual  level  is  most  subjeetive;  the  Data  Value  level  least  so. 

As  an  example,  the  OMSC  Platform  standard  objeet  would  align  with  an  AICDM  view 
eonsisting  of  entities  sueh  as  MATERIEL  that  ean  model  platforms.  The  Platform  elass  is  the 
foeal  elass  of  the  Platform  standard  objeet,  and  MATERIEL  is  the  foeal  elass  of  the  view;"^ 
sinee  they  both  model  platforms,  we  eonsider  the  foeal  entities  aligned.  We  also  need  to 
identify  the  AICDM  entities  that  align  with  Weapon,  Sensor,  Communications,  and  other 
elasses  that  are  aggregated  into  a  Platform,  and  we  need  to  ensure  that  these  entities  have 
many-to-one  relationships  to  MATERIEL  (sinee  one  Platform  ean  have  zero  or  more  Weapon, 
Sensor,  Communications,  ete.  instanees). 

We  ean  informally  eharaeterize  the  degree  of  alignment.  A  standard  objeet  implementing 
a  eoneept  eonsists  of  a  set  of  elasses.  Eaeh  OMSC  elass,  or  eaeh  AICDM  entity,  has  an 
assoeiated  pereent  degree  of  alignment,  defined  below.  The  degree  of  alignment  for  a 
standard  objeet  is  the  average  of  the  degrees  of  alignment  for  eaeh  elass  in  the  standard 
objeet.  (We  define  degree  in  terms  of  the  OMSC  beeause  an  OMSC  standard  objeet  has  a 
fixed  number  of  elasses.  By  eontrast,  in  relational  data  models  sueh  as  the  AICDM  eaeh 
entity  may  ultimately  be  related  to  every  other  entity.  The  AICDM’s  notion  of  what  eon- 
stitutes  a  eoneept  is  softer  than  the  OMSC’s.)  The  alignment  must  oeeur  between  assoeia- 
tions  and  relationships  too.  If  the  OMSC  foeal  elass  has  a  one-to-many  assoeiation  with 
some  other  elass,  the  AICDM  foeal  entity  must  have  a  one-to-many  relationship  with  the 
AICDM  entity  to  whieh  the  elass  aligns. 

We  ean  also  define  Coneeptual  level  degree  of  alignment  independent  of  the  Entity  level, 
whieh  is  useful  if  we  only  want  to  analyze  alignment  at  the  Coneeptual  level.  The  degree 
of  alignment  of  a  standard  objeet  and  a  view  is  the  pereentage  of  elasses  that  map  to  an 
AICDM  entity. 

4.2  Entity  Level 

4.2.1  Definition  of  Level 

At  this  level,  the  foeus  is  on  the  individual  entities  that  make  up  a  eoneept.  Entity  align¬ 
ment  is  aetually  very  similar  to  Coneeptual  alignment.  Entity  alignment  is  a  neeessary 
level  in  the  alignment  definition  mainly  in  that  it  provides  a  means  to  define  other  levels 
of  alignment. 


This  example  is  somewhat  simplified.  See  Appendix  A.2  for  a  full  discussion  of  the  AICDM  view  that 
is  aligned  with  the  Platform  standard  object. 
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4.2.2  Interpretation  in  AlC DM 

The  AICDM  models  an  entity  (in  the  general  sense  of  the  word)  as  a  set  of  ER  entities, 
with  assoeiated  ER  relationships.  Eisually  the  set  will  eontain  a  single  ER  entity.  How¬ 
ever,  ER  design  is  not  an  exaet  seience.  Where  one  designer  sees  as  a  single  ER  entity  as 
suffieient,  another  might  argue  for  multiple  ER  entities  assoeiated  by  one  to  one  relation¬ 
ships.  We  therefore  allow  multiple  ER  entities  to  model  a  single  real-world  entity. 

The  ER  entity  has  a  name,  suggesting  what  it  models,  and  a  set  of  named  attributes.  The 
named  attributes  suggest  characteristies  of  the  ER  entity. 

4.2.3  Interpretation  in  the  OMSC 

The  OMSC  models  an  entity  as  a  class.  A  class  has  a  name  and  a  set  of  methods,  each 
also  defined  by  name. 

Some  OMSC  classes  encapsulate  not  objects  but  a  set  of  algorithms  (Attrition  is  one  exam¬ 
ple).  These  algorithms  ultimately  operate  on  objects,  and  it  is  these  objects  that  are  of 
concern  to  alignment. 

4.2.4  Meaning  of  Alignment 

The  definition  of  alignment  is  almost  the  same  as  for  the  Conceptual  level. 

If  the  OMSC  and  the  AICDM  align  with  respect  to  some  concept,  then  each  OMSC  class 
related  to  the  concept  is  guaranteed  to  align  to  some  set  of  AICDM  entities  and  relation¬ 
ships  related  to  the  concept.  The  set  of  AICDM  entities  and  relationships  is  some  subset 
of  that  at  the  Conceptual  level.  For  example,  the  AICDM  MATERIEL  entity  aligns  with  the 
OMSC  Platform  class  at  the  Entity  level. 

Some  classes  map  to  more  than  one  ER  entity,  and  vice  versa.  This  is  a  consequence  of 
the  vagaries  of  modeling.  If  a  class  maps  to  more  than  one  ER  entity,  the  mapping  must 
include  relationships  among  the  ER  entities;  and  if  an  ER  entity  maps  to  more  than  one 
class,  the  mapping  must  include  associations  among  the  classes. 

We  define  degree  of  alignment  at  the  Entity  level  in  terms  of  State  level  alignment  below. 
Each  State  level  alignment  is  defined  by  a  percentage.  Degree  of  entity  level  alignment  is 
the  average  of  the  State  level  alignment  percentages. 

4.3  State  Level 

4.3.1  Definition  of  Level 

The  State  level  considers  the  behaviors  and  properties  of  entities.  State  alignment  means 
one  of  two  things: 

•  An  entity  in  one  model  has  the  same  properties  (i.e.,  state)  as  an  entity  in  the 
other  model. 
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•  If  an  OMSC  operation  affects  an  object  instance,  and  there  exist  OMSC  meth¬ 
ods  to  determine  that  effect,  then  there  exist  AICDM  attributes  that  can  model 
the  same  information. 

4.3.2  Interpretation  in  AICDM 

The  AICDM  models  state  using; 

•  Organic  attributes,  i.e.,  attributes  that  are  not  migrated  from  another  entity  as  a 
foreign  key.  PERSON  HEIGHTDIMENSION  is  an  organic  attribute. 

•  Attributes  from  many-to-many  relationships  between  entities  that  appear  in  as¬ 
sociative  entities.  These  attributes  fall  into  three  categories: 

•  The  foreign  keys  migrated  from  parent  to  child,  which  serve  to  record  the 
existence  of  a  relationship  between  two  instances  of  entities.  The 
ORGANIZATION-FACILITY  entity,  which  captures  the  many-to-many  relation¬ 
ship  between  ORGANIZATION  and  FACILITY,  includes  attributes  FACILITY 
IDENTIFIER,  ORGANIZATION  IDENTIFIER,  and  ORGANIZATION-FACILITY  IDENTI¬ 
FIER. 

•  Additional  attributes  needed  to  make  an  associative  entity’s  key  unique.  The 
0  R  G  AN  IZATIO  N  -F AC  I LITY  entity’s  key  also  includes  0  R  G  AN  IZATIO  N  -FAC  I LITY 
IDENTIFIER. 

•  Other  attributes  of  an  associative  entity,  which  capture  additional  informa¬ 
tion  about  the  relationship.  The  ORGANIZATION-FACILITY  EFFECTIVE  BEGIN 
CALENDAR  DATE-TIME  attribute  is  an  example. 

The  distinction  between  the  categories  of  attributes  from  many-to-many  relationships  is 
significant  because  the  first  and  second  categories  exist  as  modeling  artifacts  to  imple¬ 
ment  relationship  existence,  not  to  model  application  data.  For  instance,  an  M&S  applica¬ 
tion  might  want  to  retrieve  the  ORGANIZATION-FACILITY  EFFECTIVE  BEGIN  CALENDAR  DATE¬ 
TIME  attribute’s  value,  but  it  should  not  need  attributes  of  ORGANIZATION-FACILITY  in  the 
first  two  categories  (such  as  ORGANIZATION-FACILITY-IDENTIFIER,  which  exists  only  to  en¬ 
sure  that  each  record  in  the  ORGANIZATION-FACILITY  table  is  unique). 

As  just  illustrated,  attributes  from  many-to-many  relationships  often  describe  temporal 
properties.  That  a  relationship  exists  between  two  entities  implies  a  certain  association 
during  a  specified  period  of  time.  Organic  attributes,  by  contrast,  are  more  often  used  to 
describe  fundamental,  unchanging  properties  of  an  individual  entity. 

4.3.3  Interpretation  in  the  OMSC 

In  an  object  oriented  model,  state  is  queried  or  modified  using  methods.  There  are  two 
types  of  methods: 

1.  A  method  with  no  side  effects.  Such  a  method  is  used  to  query  the  state  of  an  object 
instance;  it  retrieves  some  property  of  the  state.  These  methods  tell  us  the  type  of  state 
information  associated  with  a  class. 

2.  A  method  with  side  effects.  Such  a  method  is  behavioral.  The  next  invocation  of  one 
of  the  side-effect  free  methods  will  reflect  the  instance’s  altered  state.  These  methods 
inform  us  about  the  types  of  operations  an  instance  of  the  class  can  perform. 
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(A  method  may  have  side  effeets  and  also  retrieve  the  altered  state.  We  treat  this  as 
equivalent  to  having  a  side  effeet.) 

At  this  level  in  the  OMSC,  a  method  is  modeled  by  a  name  and  a  textual  deseription  of  its 
purpose.  We  rely  on  intuition  for  a  method’s  return  type  and  parameters. 

4.3.4  Meaning  of  Alignment 

Alignment  at  the  State  level  means  that  there  is  a  suitable  mapping  between  OMSC 
methods  and  AICDM  attributes  and  relationships.  More  precisely: 

•  If  an  OMSC  method  has  no  side  effects,  then  it  aligns  to  a  set  of  AICDM  or¬ 
ganic  attributes  and  attributes  from  the  relationships  if  the  method’s  description 
implies  the  method  returns  a  value  that  is  modeled  by  the  organic  attributes  and 
attributes  from  the  relationships. 

•  If  an  OMSC  method  has  a  side  effect,  then  it  aligns  to  a  set  of  AICDM  organic 
attributes  and  attributes  from  the  relationships  if: 

•  The  method’s  description  implies  the  method  changes  those  organic  attributes 
and  attributes  from  the  relationships. 

•  If  we  can  infer  parameters  for  the  method,  the  organic  attributes  and  attributes 
from  the  relationships  must  include  values  for  those  parameters. 

Sometimes  an  OMSC  return  value  (or  parameter)  aligns  to  a  single  attribute,  but  often  it 
aligns  to  more  than  one.  This  is  a  consequence  of  some  combination  of  the  following: 

•  A  method  returns  (or  uses)  a  composite  value. 

•  A  method  operates  on  several  classes  of  entities.  For  instance,  the 
conductMaintenanceO  method  of  the  Maintenance  class  operates  on  both  platforms 
(equipment  maintenance)  and  persons  (medical  treatment). 

An  OMSC  method’s  return  value  or  parameter  can  align  to  attributes  and  relationships 
either  directly  or  indirectly.  Direct  alignment  means  there  exists  an  AICDM  attribute  that 
stores  the  return  (or  parameter)  value.  For  instance,  the  getLatitudeO  method  of  the 
OMSC’s  LatLon  class  returns  a  value  that  is  stored  by  the  POINT  LATITUDE  COORDINATE  at¬ 
tribute. 

Indirect  alignment  means  the  AICDM  does  not  have  an  attribute  that  stores  the  method’s 
return  (or  parameter)  value,  but  the  value  can  be  computed  based  on  other  attributes  and 
relationships.  Consider  the  OMSC’s  Supply  class,  which  has  methods  getTotalCapacItyO, 
getQtyOnHandO,  and  getRemalnIngCapacItyO.  The  getTotalCapacItyO  and  getQtyOnHandO  methods 
align  directly,  but  the  AICDM  has  no  attributes  that  store  remaining  capacity.  However, 
the  result  of  getRemalnIngCapacItyO  can  be  computed  as  the  difference  between 
getTotalCapacItyO  and  getQtyOnHandO. 

State  Level  alignment  is  defined  with  respect  to  Entity  Level  alignment.  Side  effect  or  no 
side  effect,  direct  or  indirect,  method  M  of  class  C  and  attribute  A  of  entity  E  can  only  be 
aligned  at  the  State  level  if  C  and  E  are  aligned  at  the  Entity  level  (more  exactly,  if  E  is 
among  the  set  of  entities  that  are  aligned  with  C). 
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Sometimes,  a  method’s  return  value,  or  one  of  its  parameters,  aligns  to  a  set  of  attributes 
that  happen  to  be  an  AICDM  entity.  An  example  is  the  method  getLocationO,  whieh  returns 
a  value  that  aligns  to  the  LOCATION  entity.  LOCATION  is  in  turn  the  root  of  a  subtype  hierar¬ 
chy;  the  hierarchy  forms  a  view.  In  such  situations.  State  level  alignment  is  defined  in 
terms  of  Conceptual  alignment.  In  other  words,  getLocationO  is  aligned  with  LOCATION  to 
the  degree  that  LOCATION  aligns  with  some  AICDM  view  for  locations. 

Degree  of  alignment  at  the  State  level  does  not  have  a  precise  definition.  That  would  re¬ 
quire  the  OMSC  to  supply  information  on  method  parameters  and  return  types.  Instead, 
we  define  degree  of  alignment  at  the  State  level  in  terms  of  how  clearly  we  can  map  what 
we  expect  are  the  method’s  parameters  and  return  values  to  attributes  of  the  ER  entities 
aligned  to  the  method’s  class.  This  mapping  considers  the  following  factors: 

•  Is  there  a  single  attribute,  or  are  there  several  candidate  attributes? 

•  How  closely  does  the  intent  of  the  attribute  appear  to  match  the  intent  of  the  pa¬ 
rameter/return  value?  (Sometimes  we  can  define  this  in  terms  of  Data  Value 
alignment.  For  example,  the  OMSC  Location  class  can  model  both  geodetic  and 
artificial  two-dimension  and  three-dimensional  spaces.  The  corresponding 
AICDM  attribute  in  the  Location  entity  can  only  describe  geodetic  references.) 

•  Is  there  a  way  to  force-fit  the  mapping?  Many  AICDM  attributes  entities  have 
attribute  pairs  in  which  one  attribute  stores  a  value  and  the  other  stores  a  code 
telling  how  to  interpret  that  value.  Sometimes,  legal  values  for  this  code  include 
“other”  and  “undefined”.  Either  could  be  used  to  create — albeit  poorly — a 
mapping. 

•  The  degree  of  alignment  for  a  method  that  aligns  indirectly  usually  comes  from 
the  degree  of  alignment  of  other  methods.  For  example,  getRemalnIngCapacItyO 
has  a  degree  of  alignment  that  is  the  minimum  of  the  degrees  of  alignment  of 
the  two  methods  used  to  compute  its  value,  getQtyOnHandO  and  getTotalCapacItyO. 

4.4  Data  Value  Level 

4.4.1  Definition  of  Level 

The  Data  Value  level  considers  the  overlap  of  domains.  The  key  issue  is  the  degree  to 
which  values  from  a  data  type  in  one  model  can  be  mapped  to  another  model.  They  may 
map  partially,  fully,  or  not  at  all. 

4.4.2  Interpretation  in  AICDM 

Each  AICDM  attribute  has  a  data  type.  The  data  type  is  usually  described  according  to 
standardized  definitions  contained  in  the  Defense  Data  Dictionary  System  (DDDS). 

4.4.3  Interpretation  in  the  OMSC 

The  current  version  of  the  OMSC  does  not  specify  data  type  information. 

4.4.4  Meaning  of  Alignment 

For  a  data  value  in  one  model  to  align  fully  with  a  value  in  the  other  model,  both  must 
have  exactly  the  same  data  type  and  domain.  It  must  be  possible  to  represent  exactly  the 
same  values,  to  the  same  degree  of  precision. 
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Also,  an  OMSC  data  value  must  be  assoeiated  with  a  method  that  aligns  with  a  eorre- 
sponding  AICDM  attribute  at  the  State  level. 

Degree  of  alignment  is  a  funetion  of  the  pereentage  of  values  that  overlap.  Consider  an 
AICDM  domain  A  and  OMSC  domain  O.  One  might  be  a  subset  of  the  other.  For  exam¬ 
ple,  the  OMSC  and  the  AICDM  model  postures,  but  the  OMSC  has  a  broader  set  of  pos¬ 
tures  (see  Figure  8-a).  Or  the  two  domains  might  have  some  values  in  eommon,  but  eaeh 
may  also  possess  unique  values.  For  example,  both  the  AICDM  and  the  OMSC  model 
loeations,  but  only  the  OMSC  models  Cartesian  eoordinates,  and  the  AICDM  models 
geodetie  eoordinates  to  greater  preeision  than  the  OMSC  (see  Figure  8-b). 

Suppose  both  domains  are  diserete.  Their  degree  of  alignment  is  \A  n  0\l\A  u  0\ ,  the 

eardinality  of  the  interseetion  of  the  two  domains  divided  by  the  eardinality  of  the  union. 
Degree  of  alignment  is  a  value  between  0  and  1,  with  1  being  perfeet  alignment  and  0  be¬ 
ing  no  alignment. 


a.  Posture  Domain  Overlap  b.  Location  Domain  Overlap 

Figure  8.  Examples  of  Value  Level  Domain  Overlap 

The  Value  level  is  the  deepest,  most  rigorous  level.  Only  at  this  level  ean  data  alignment 
really  be  determined,  in  the  sense  of  understanding  whether  fully  automated  translation 
between  two  data  models  is  possible.  But  for  the  time  being,  working  at  the  Value  level  is 
impossible.  It  requires  detail  that  the  OMSC  does  not  begin  to  provide.  We  inelude  the 
Value  level  to  suggest  future  direetions  for  determining  alignment,  and  also  as  a  guide  to 
the  eompleteness  of  the  AICDM  and  the  OMSC. 
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5.  Assessing  Alignment 


This  section  covers  the  process  we  followed  to  determine  alignment  between  the  AICDM 
and  the  OMSC.  The  purpose  of  presenting  the  process  is  to  allow  for  continued  analysis 
of  alignment  as  OMSC  standard  objects  become  available.  Following  the  process  helps 
ensure  uniformity  of  analysis. 

5.1  Overview 

We  performed  analysis  at  the  Conceptual,  Entity,  and  State  levels.  We  first  determined 
alignment  at  the  Conceptual  level,  used  the  results  of  Conceptual  alignment  as  a  guide  in 
determining  alignment  at  the  Entity  level,  and  then  used  the  results  of  Entity  alignment  to 
guide  alignment  at  the  State  level.  We  obtained,  for  each  method,  a  numeric  estimate  of 
the  degree  of  State  level  alignment  between  the  AICDM  and  the  OMSC  with  respect  to 
that  method.  We  then  averaged  these  numeric  estimates  into  an  estimate  of  the  degree  of 
Entity  level  alignment  between  the  AICDM  and  the  OMSC  with  respect  to  each  entity, 
and  averaged  the  entity  estimates  into  a  value  for  the  degree  of  Conceptual  level  align¬ 
ment  with  respect  to  each  OMSC  standard  object. 

We  started  with  OMSC  standard  objects  and  found  corresponding  AICDM  views.  We 
could  have  started  with  AICDM  views  and  identified  corresponding  OMSC  standard  ob¬ 
jects,  but: 

•  Our  task  focused  on  identifying  AICDM  extensions  which  might  be  required  to 
accommodate  M&S  data  requirements  as  defined  by  OMSC  standard  objects. 
The  OMSC  therefore  defines  our  task  scope. 

•  The  OMSC  is  much  smaller  than  the  AICDM.  Most  AICDM  views  don’t  map 
to  OMSC  standard  objects,  at  least  not  yet.  For  the  time  being,  starting  with  the 
OMSC  narrows  the  task. 

•  The  predefined  AICDM  views  are  broader  than  OMSC  standard  objects.  Had 
we  started  with  the  AICDM,  we  would  have  found  that  any  given  view  over¬ 
lapped  most  of  the  OMSC.  This  was  evident  from  quick  examinations  of  each 
model  even  before  we  started  the  analysis. 

•  An  object  has  a  state,  defined  by  its  methods,  and  data/object  model  alignment 
determines  the  degree  to  which  the  data  model  captures  states  of  the  object 
model. 

Note  that  alignment  analysis  is  asymmetric.  Using  the  OMSC  AICDM  orientation,  we 
calculate  average  values  based  on  (for  example)  the  number  of  methods  in  a  class.  If  we 
had  chosen  an  AICDM  OMSC  orientation,  we  would  have  averaged  the  degrees  of 
alignment  of  each  attribute  in  an  entity.  There  isn’t  a  one-to-one  correspondence  between 
AICDM  entities  and  OMSC  classes,  or  between  AICDM  attributes  and  OMSC  methods. 
Therefore,  we  obtain  different  sets  of  averages  based  on  the  orientation  we  choose.  Fur¬ 
thermore,  we  deliberately  ignore  many  AICDM  attributes  that  aren’t  relevant  to  OMSC 
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methods.  For  example,  the  MATERIEL-ITEM  entity,  which  records  information  about  types 
of  materiel,  has  a  MATERIEL-ITEM  PREFERRED  INSPECTION  PLACE  CODE  attribute  that  desig¬ 
nates  whether  a  type  of  materiel  should  be  inspected  at  its  source  or  destination.  This  at¬ 
tribute  is  irrelevant  to  simulations,  at  least  as  far  as  the  OMSC  is  concerned,  and  would 
not  align  to  any  OMSC  method.  But  alignment  analysis  looks  for  attributes  that  match 
methods,  not  methods  that  match  attributes,  so  the  absence  of  a  method  aligning  to  the 
MATERIEL-ITEM  PREFERRED  INSPECTION  PLACE  CODE  attribute  doesn’t  show  up  in  the 
analysis. 

5.2  Process 

For  each  OMSC  standard  object,  we  identified  the  related  AICDM  view.  In  fact  no  prede¬ 
fined  AICDM  view  exactly  matches  the  intent  of  an  OMSC  standard  object,  so  we  noted 
the  relevant  AICDM  entities  and  associations;  these  formed  a  view  that  served  our  pur¬ 
poses. 

We  mapped  each  OMSC  class  in  a  standard  object  to  AICDM  entities  within  the  associ¬ 
ated  view.  We  mapped  each  OMSC  method  in  a  class  to  attributes  within  an  entity.  Some¬ 
times  the  attributes  were  distributed  across  several  entities.  This  occurred  because  of 
AICDM  subtyping  (e.g.,  subclasses  of  Location)  or  because  the  AICDM’s  designers 
opted  to  represent  the  concept  described  by  an  OMSC  class  as  several  entities.  In  either 
case,  we  noted  the  associations  (inheritance,  relationships,  or  both)  among  the  entities. 

At  this  point,  the  OMSC  usually  lacked  detail  and  forced  us  to  start  making  assumptions. 
We  had  to  hypothesize  the  ranges  of  a  method’s  return  value  and  parameters. 

Having  made  these  assumptions,  we  were  sometimes  able  to  analyze  the  data  values 
which  we  hypothesized  an  M&S  system  would  use.  The  point  of  this  analysis  was  not 
exactly  to  determine  alignment.  Instead,  it  was  to  investigate  data  values  associated  with 
the  AICDM  (determined  through  the  DDDS).  We  often  had  to  search  the  AICDM  to  de¬ 
termine  if  the  an  AICDM  attribute  mapped  to  what  we  thought  would  be  a  value  returned 
or  used  by  an  OMSC  method. 

5.3  Example 

The  following  example  of  alignment  illustrates  the  process.  It  shows  part  of  the  analysis 
of  alignment  between  the  OMSC  standard  object  Unit  and  the  AICDM  model.  The  results 
of  the  analysis  are: 

•  A  calculation  of  the  degree  of  alignment  between  the  standard  object  Unit  and  a 
view  we  define. 

•  Details  on  the  alignment,  down  to  the  State  level. 

5.3.1  Conceptual  Level 

We  begin  by  choosing  conceptual  level  entities  and  analyzing  how  closely  they  are 
aligned.  We  choose  the  OMSC  standard  object  Unit  as  the  focus  of  this  example. 

The  OMSC  defines  Unit  as  follows  [HB  1998 A]: 
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A  Unit  encompasses  military  organizations  that  represent  collections  of  entities 
(e.g.,  people,  vehicles,  weapon  systems,  etc.).  Examples  of  this  definition  include 
organizations  (i.e.,  companies,  battalions,  brigades,  divisions,  etc.)  as  well  as 
functional  groups  (e.g..  Tactical  Operations  Centers  and  Fire  Control  Centers). 

We  examine  the  Unit  standard  objeet  (see  Figure  5),  looking  for  its  foeal  elass.  The  Unit 
elass  appears  apt.  It  is  elearly  the  root  of  a  elass  hierarehy  that  ineludes  aggregation  and 
subtype  assoeiations.  Its  name,  whieh  is  the  same  as  that  of  the  standard  objeet,  also  sug¬ 
gests  its  eentral  role. 

We  examine  the  AICDM  model.  We  observe  that  it  eontains  an  entity  named 
ORGANiZATiON,  whieh  appears  relevant.  We  further  observe  an  entity  named  MILiTARY-UNiT 
that  is  a  subtype  (though  not  direetly)  of  ORGANiZATiON.  MILiTARY-UNiT  would  appear  to  be 
an  appropriate  ehoiee  as  the  foeal  entity  of  the  view  we  eonstruet.  See  Figures  A-8  and 
A-9. 


We  examine  the  predefined  AICDM  views  and  note  that  the  Organization  view  eontains 
both  ORGANiZATiON  and  MiLiTARY-UNiT.  The  Organization  view  appears  to  be  a  good  start¬ 
ing  point  for  building  our  view. 

Looking  through  the  OMSC  elasses  in  the  Unit  standard  objeet,  we  see  the  need  to  model 
the  eoneepts  listed  in  Table  4. 

Table  4.  Concepts  Suggested  by  the  Unit  Standard  Object 


Concept 

Suggested  By  OMSC  Class 

Communications 

Communications 

1  ntelligence 

Intel 

Materiel 

Logistics,  Maintenance,  and  Supply 

Geometry 

Unite  eometry 

People 

Attrition 

Platform 

Platform  and  SystemGroup 

C2 

C2 

The  Organization  view  does  not  model  all  of  these  eoneepts.  We  examine  the  other  prede¬ 
fined  AICDM  views  and  find  that  none  fully  eaptures  the  eoneept  expressed  by  the  Unit 
standard  objeet. 

We  turn  to  the  eomplete  AICDM  model,  and  add  AICDM  entities  to  the  pre-existing 
Organization  view  to  obtain  the  view  we  are  defining,  whieh  we  term  the  Military  Unit 
view.  Geometry  is  modeled  by  the  LOCATiON  entity.  The  others  are  less  eertain.  MATERiEL 
seems  a  reasonable  mateh  for  P  iatform,  although  FACiLiTY  might  work  too.  The  AICDM  has 
no  entity  exaetly  matehing  intelligenee;  it  does  have  iNTELLiG  ENG  E-RESOURCE 
EMPLOYEMENT.  It  also  has  the  SENSOR-TYPE  entity,  whieh  seems  useful  in  intelligenee  eol- 
leetion. 

The  AICDM  has  many  entities  related  to  eommunieations.  All  seem  to  be  prefixed  with 
TELECOMMUNICATIONS-NETWORK.  Examples  inelude  TELECOMMUNICATIONS-NETWORK 
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ELEMENT  and  TELECOMMUNICATIONS-NETWORK  DEVICE.  We  include  these  entities  in  our 
Military  Unit  view. 

There  are  in  fact  other  things  in  the  AICDM  that  we  need  to  align  to  the  OMSC.  For  in¬ 
stance,  we  have  assumed  that  attrition  applies  only  to  people,  but  in  fact  attrition  can  ap¬ 
ply  to  both  equipment  and  people.  Nothing  in  the  OMSC  that  we  have  studied  so  far  has 
this  much  detail  on  attrition,  so  we  don’t  know  that  yet.  Entity  level  analysis  reveals  it. 

5.3.2  Entity  Level 

A  complete  analysis  of  Entity  level  alignment  involves  an  analysis  of  each  OMSC  class 
in  the  Unit  standard  object.  In  this  example,  we  focus  on  the  Unit  class. 

The  OMSC  Unit  class  aligns  with  the  AICDM  entity  MILITARY-UNIT,  the  focal  entity  of  our 
Military  Unit  view.  Examining  the  names  of  Unit’s  methods,  we  can  see  the  need  for  other 
AICDM  entities  and  relationships  if  an  instance  of  Unit  is  to  be  fully  modeled  in  the 
AICDM,  because  the  attributes  of  MILITARY-UNIT  do  not  appear  to  encompass  the  range  of 
concepts  those  methods  comprise.  So  we  add  them,  making  certain  they  are  related  to  a 
MILITARY-UNIT: 

Tables.  Relationship  of  AICDM  Entities  to  MILITARY-UNIT  Entity 


AICDM  Entity 

Suggested  by 
OMSC  Method 

Relationship  to  MILITARY-UNIT 

ORGANIZATION 

N/A  (supertype 
of  focal  entity) 

MILITARY-UNIT  is  a  subtype  of  UNIFORMED-SERVICE- 
ORGANIZATION. 

UNIFORMED-SERVICE-ORGANIZATION  isa  subtype  of 
0RGANIZATI0N.5 

LOCATION  (and  its 
subtypes) 

getLocationO 

moveO 

MILITARY-UNIT  is  a  subtype  of  ORGANIZATION. 
ORGANIZATION  has  a  many-to-many  relationship 
with  FEATURE: 

•  ORGANIZATION  participates  in  ORGANIZATION- 
FEATURE. 

•  FEATURE  participates  in  ORGANIZATION-FEATURE. 
CONTROL-FEATURE  is  a  subtypeof  FEATURE.e 

FEATURE  has  a  many-to-many  relationship  with 
LOCATION: 

•  FEATURE  occupies  FEATURE-LOCATION. 

•  LOCATION  locates  FEATURE -LOCATION. 

^  For  brevity,  the  remaining  rows  in  this  table  omit  the  reference  to  UNIFORME D-S E R VIC E- 
ORGANIZATION. 

^  The  C 0 NTR 0  L-F  E ATU  R  E  entity  is  used  to  record  an  organization’s  location.  See  Appendix  A  for  de¬ 
tails.  An  organization’s  location  may  also  be  described  as  follows:  ORGANIZATION  occupies  ORGANI¬ 
ZATION-LOCATION;  ORGANIZATION-LOCATION  locates  LOCATION.  In  the  March  2001  version  of  the 
AICDM,  either  was  acceptable.  In  more  recent  versions,  a  C 0 NTR 0  L-F  E ATU  R  E  is  used  to  describe  an 
organization’s  spread  over  an  area,  and  an  organization’s  center  of  mass  is  modeled  as  a  a  POINT.  See 
Appendix  E. 


36 


AICDM  Entity 

Suggested  by 
OMSC  Method 

Relationship  to  MILITARY-UNIT 

ORGANIZATION- 

OPERATIONAL- 

STATUS 

getStatusO 

getPostureO 

MILITARY-UNIT  is  a  subtype  of  ORGANIZATION. 
ORGANIZATION  is  described  by  ORGANIZATION 
OPERATIONAL  STATUS. 

MISSION 

getMissionO 

ORGANIZATION  has  a  many-to-many  relationship 
with  MISSION: 

•  ORGANIZATION  is  referenced  in  MISSION- 
ORGANIZATION. 

•  MISSION  is  controlled  by  MISSION-ORGANIZATION. 

ORGANIZATION-TYPE- 
ORGANIZATION 
HOLDING  ESTIMATE 

determineAttritionO 

MILITARY-UNIT  is  a  subtype  of  ORGANIZATION. 
ORGANIZATION  provides  ORGANIZATION-TYPE- 
ORGANIZATION-HOLDING -ESTIMATE. 

PERSON-TYPE- 
ORGANIZATION 
HOLDING  ESTIMATE 

determineAttritionO 

MILITARY-UNIT  is  a  subtype  of  ORGANIZATION. 
ORGANIZATION  provides  PERSON-TYPE- 
ORGANIZATION-HOLDING -ESTIMATE. 

We  note  an  ambiguity  at  this  stage  of  the  analysis.  The  OMSC  states  that  a  loeation  is 
typieally  a  point  representing  a  eenter  of  mass.  Apparently  it  ean  be  something  other  than 
a  point.  Perhaps  it  is  one  of  the  geometrie  figures  modeled  by  the  AICDM  entity 
REGULAR-AREA.  For  this  reason  we  inelude  all  subtypes  of  LOCATION. 

5.3.3  State  Level 

We  eontinue  the  alignment  analysis  at  the  State  level  by  examining  eaeh  method  of  the 
Unit  elass. 

The  getLocationO  Method 

From  the  method’s  deseription,  we  infer  that  it  returns  a  value  that  represents  a  Location. 
The  OMSC  defines  a  LOCATION  elass  hierarehy.  This  hierarehy  eonstitutes  another  stan¬ 
dard  objeet.  We  therefore  revert  to  Coneeptual  level  alignment  analysis  to  determine  if 
there  exists,  or  if  we  ean  define,  an  AICDM  view  that  aligns  with  Location.  We  diseover 
that  the  OMSC  Location  standard  objeet  partially  aligns  with  a  view  eonsisting  of  the 
AICDM’s  LOCATION  entity  and  its  subtypes. 

The  getVelocityO  Method 

This  method’s  deseription  indieates  that  it  returns  the  veloeity  of  a  Unit.  We  fail  to  find 
any  mapping  to  the  AICDM,  whieh  does  not  model  motion  of  organizations.  We  eonelude 
there  is  no  alignment  at  the  State  level  between  getVelocityO  and  the  AICDM. 

The  getIDO  Method 

We  find  some  ambiguity  in  aligning  the  getlD()  method,  beeause  the  AICDM  has  many 
attributes  that  might  be  relevant.  We  eannot  aseertain  whieh  (if  any)  is  appropriate  with¬ 
out  more  detail  from  the  OMSC.  This  eannot  be  resolved  exeept  at  the  Value  level,  and 
the  OMSC  does  not  supply  the  neeessary  information  to  eonduet  analysis  at  that  level. 
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The  getIDO  method  might  map  to  any  of  the  following  AICDM  attributes  of  MILITARY-UNIT; 

•  MILITARY-UNIT  ALTERNATE  IDENTIFIER 

•  MILITARY-UNIT  REFERENCE  NUMBER  ID 

•  MILITARY-UNITTROOP  PROGRAM  IDENTIFIER 

•  MILITARY-UNIT  FOREIGN  MILITARY  TRANSLATED  NAME 

•  MILITARY-UNIT  IDENTIFIER 

The  getSIdeO  Method 

Examining  the  attributes  of  AICDM  entities,  we  find  the  AICDM  does  not  model  sides  in 
the  same  way  as  the  OMSC.  The  AICDM  has  attributes  that  allow  an  organization  to  be 
designated  as  friend,  foe,  neutral,  or  various  other  values.  It  also  has  an  entity  ENEMY- 
ORGANIZATION.  The  problem  is  that  it  does  not  allow  for  arbitrary  sides.  The  AICDM  does 
not  explieitly  model  eoalitions  and  their  allegianees. 

However,  getSIdeO  does  not  speeify  enmity.  In  other  words,  the  AICDM  does  not  need  to 
model  allegianees  to  align  with  getSIdeO.  It  only  needs  to  model  the  existenee  of  sides. 
The  AICDM  ean  do  this  indireetly  through  the  ORGANIZATION-ASSOCATION  entity,  whieh 
has  a  relationship  with  ORGANIZATION.  The  relationship  is  used  to  model  organizational 
hierarehies.  Sinee  a  eoalition  (or  faetion)  is  a  type  of  hierarehy,  we  ean  model  a  eoalition 
(or  faetion)  as  an  ORGANIZATION,  related  to  other  ORGANIZATION  entities  via  an 
ORGANIZATION-ASSOCIATION  entity: 

•  We  ereate  an  ORGANIZATION  as  the  root  of  the  hierarehy.  The  ORGANIZATION- 
IDENTIFIER  attribute  eontains  the  name  of  the  faetion  or  eoalition. 

•  For  eaeh  ORGANIZATION  that  is  a  member  of  the  faetion  or  eoalition,  we  relate  it 
to  the  root  ORGANIZATION  via  an  assoeiation  through  an  instanee  of  the 
ORGANIZATION-ASSOCIATION  entity: 

•  ORGANIZATION  is  the  subjeet  of  ORGANIZATION-ASSOCIATION 

•  ORGANIZATION  is  the  objeet  of  ORGANIZATION-ASSOCIATION 

Note  that  nothing  explieitly  identifies  the  root  ORGANIZATION  as  denoting  a  eoalition.  The 
DESCRIPTION  TEXT  attribute  eould  be  used,  but  that’s  just  prose.  None  of  the  other  attrib¬ 
utes  have  a  suitable  value  (though  we  don’t  diseover  this  until  we  analyze  alignment  at 
the  Data  level). 

The  getPostureO  Method 

The  OMSC  is  rather  vague  about  the  definition  of  posture.  But  then,  so  is  the  Army.  In 
any  ease,  the  AICDM  entities  have  several  attributes  that  seem  to  offer  the  possibility  to 
model  posture: 

•  ORGANIZATION-OPERATIONAL-STATUS  PROTECTIVE  POSTURE  CODE 

•  ORGANIZATION-OPERATIONAL-STATUS  CURRENT  ACTIVITY  CODE 

•  MILITARY-UNIT  CURRENT  ACTIVITY  CODE 

However,  none  of  these  names  seems  to  suggest  the  ability  to  aeeommodate  the  full  range 
of  postures  suggested  by  the  deseriptive  text  for  the  method.  We  note  the  possibilities  and 
wait  until  we  perform  Data  level  analysis. 
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The  getStatusO  Method 


The  OMSC  is  also  vague  about  status.  In  the  AICDM  the  following  attributes  are  possi¬ 
bilities,  but  none  of  the  names  seem  to  suggest  the  ability  to  aeeommodate  the  full  range 
of  statuses  suggested  by  the  deseriptive  text  for  the  method: 

•  ORGANIZATION-OPERATIONAL-STATUS  COMBAT  EFFECTIVENESS  CODE 

•  ORGANIZATION-OPERATIONAL-STATUS  COMBAT  READINESS  CODE 

•  MILITARY-UNITCURRENTREADINESS  CONDITION  CODE 

•  MILITARY-UNIT  DEFENSE  READINESS  CONDITION  CODE 

The  getMIsslonO  Method 

We  read  the  deseription  of  this  method  and  realize  that,  in  M&S  systems,  a  mission  is 
prose.  This  eontradiets  our  earlier  assumption  that  the  result  of  getMIsslonO  aligns  with  a 
MISSION  (see  Table  5).  A  MISSION  eomprises  a  set  of  TASK  entities.  The  TASK  entities  have 
a  free  text  attribute  (TASK-DESCRIPTION-TEXT).  The  getMIsslonO  method  aligns  better  with 
TASK  than  with  MISSION. 

The  alignment  is  unidireetional.  An  AICDM  TASK  may  be  a  hierarehy.  We  might  map  this 
to  an  AICDM  mission  using  some  standard  algorithm  for  amalgamating  the  task  deserip- 
tions  in  the  hierarehy,  but  we  eouldn’t  neeessarily  reeover  the  original  strueture  from 
getMIsslonO. 

The  getEchelonO  Method 

The  return  value  of  this  method  maps  to  the  MILITARY-ORGANIZATION  UNIT-LEVEL  CODE  at¬ 
tribute. 

The  moved  Method 

This  is  a  behavioral  method.  The  OMSC  does  not  speeify  any  parameters,  but  movement 
is  direeted  and  so  the  method  must  obtain  its  destination  from  somewhere.  It  seems  safe 
to  assume  that  most  M&S  systems  will  invoke  the  method  with  parameters. 

There  are  two  obvious  parameter  sehemes  that  eould  be  used.  The  parameters  eould  eon- 
sist  of: 

1.  Anew  loeation,  probably  speeified  as  a  Location  objeet  (i.e.,  as  a  Cartesian  eoordinate). 
Possibly  it  eould  be  stated  as  a  name  (e.g.,  “Roekefeller  Center”)  but  that  would  mean 
the  Unit  elass  must  interfaee  with  a  mapping  system.  The  OMSC  deseriptions  of  Unit 
haven’t  provided  any  evidenee  thereof 

The  AICDM  ean  partly  model  a  Location  objeet,  as  noted  above  in  the  deseription  of 
getLocatlonO.  A  LOCATION,  then,  would  sometimes  be  a  suitable  mapping  of  the  parame¬ 
ter  to  moved  under  this  seheme. 

2.  A  veetor,  relative  to  the  eurrent  loeation.  A  unit  might  be  instrueted  to  move  100  yards 
forward,  for  instanee. 

Whether  the  AICDM  ean  model  this  seheme  depends  on  how  the  direetion  is  speei¬ 
fied.  The  AICDM  does  not  model  organization  alignment  and  so  eannot  model  diree- 
tions  sueh  as  “forward”  that  are  relative  to  alignment. 
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There  is  also  no  entity  in  the  AICDM  that  eaptures  the  eoneept  of  relative  motion. 
Perhaps  an  OMSC  speeifieation  of  relative  motion  would  map  to  an  AICDM  TASK. 
But  a  TASK  is  more  general  than  just  a  motion  speeifieation,  and  so  eannot  be  mapped 
baek. 

In  either  ease,  the  AICDM  must  be  able  to  model  the  state  before  and  after  the  method  is 
invoked. 

The  ehange  in  state  eonsists  of  a  ehange  to  a  unit’s  loeation.  The  AICDM  is  able  to  model 
this  ehange,  beeause  an  ORGANIZATION  has  an  assoeiated  LOCATION.  The  assoeiation  is 
through  relationships  involving  an  entity  ORGANIZATION-LOCATION,  whieh  has  attributes 
ORGANIZATION-LOCATION  EFFECTIVE  CALENDAR  DATE  and  ORGANIZATION-LOCATION 
EFFECTIVE  TIME.  These  attributes  are  partieularly  useful  in  keeping  a  history  of  state,  if 
desired. 

The  determlneAttrltlonO  Method 

This  is  a  behavioral  method.  The  deseription  states  that  it  ealeulates  attrition  eaused  by 
another  unit  or  platform.  We  ean  infer  the  following: 

1.  Attrition  is  ealeulated  with  respeet  to  some  previous  state  of  the  unit.  The  duration 
between  the  time  of  that  state  and  the  present  is  either  fixed  or  speeified  as  a  parame¬ 
ter. 

In  either  ease,  the  time  of  the  previous  state  would  align  to  an  AICDM  attribute.  The 
assoeiations  between  an  ORGANIZATION  and  its  personnel  or  materiel  inelude  attributes 
that  reeord  the  date  and  time  during  whieh  the  assoeiation  applies. 

2.  The  method’s  deseription  refers  to  “another  unit  or  platform”  in  the  singular.  This  im¬ 
plies  that  attrition  is  ealeulated  with  respeet  to  a  single  unit  or  platform.  Sinee  simula¬ 
tions  have  many  units  and  platforms,  the  one  that  eauses  attrition  would  need  to  be  a 
parameter  of  determlneAttrltlonO. 

We  therefore  expeet  that  at  least  one  parameter  of  determlneAttrltlonO  would  align  to  a 
MILITARY-UNIT  or  MATERIAL-ITEM  of  the  AICDM. 

The  ehange  in  state  eaused  by  determlneAttrltlonO  will  be  the  loss  of  personnel,  materiel,  ete. 
from  a  unit.  How  this  is  done  depends  on  whether  the  simulation  models  individual  enti¬ 
ties  or  quantity  of  entities;  e.g.,  whether  it  reeords  that  a  unit  has  tanks  identified  A,  B, 
and  C  or  simply  notes  that  the  unit  has  3  tanks.  If  it  models  individual  entities,  then  the 
ehange  in  state  aligns  to  the  following  AICDM  attributes: 

•  PERSON-ORGANIZATION  BEGIN  CALENDAR  DATE-TIME 

•  PERSON-ORGANIZATION  END  CALENDAR  DATE-TIME 

•  MATERIEL-ORGANIZATION  (N.B.  MATERIEL-ORGANIZATION  is  an  entity,  and  it  laeks 
a  date-time  attribute  to  reeord  when  the  assoeiation  exists.) 

If  the  simulation  models  entity  quantity,  the  ehange  in  state  aligns  to  the  following 
AICDM  attributes: 

•  PERSON-TYPE-ORGANIZATION-HOLDING-ESTIMATE  OUANTITY, 
PERSON-TYPE-ORGANIZATION-HOLDING-ESTIMATE  CALENDAR  DATE-TIME 

•  MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE  OUANTITY, 
MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE  CALENDAR  DATE-TIME 
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The  AICDM  can  model  more  types  of  quantity  changes  than  associations  with  individual 
entities.  However,  modeling  attrition  of  facilities,  features,  and  organizations  may  not  be 
important. 

The  effect  of  determineAttritionO  might  also  be  modeled  using  the  AICDM  ACTION-EFFECT 
entity.  However,  a  decision  was  made  to  postpone  doing  so  until  the  OMSC  has  a  better- 
defined  model  of  behavior.  See  p.31. 

5.3.4  Value  Level 

We  cannot,  as  a  rule,  determine  alignment  at  this  level.  The  OMSC  lacks  detail.  We  can, 
however,  make  inferences  based  on  statements  in  the  OMSC  and  the  known  values  for 
the  AICDM.  Mostly  this  is  a  matter  of  understanding  whether  the  range  of  possible  val¬ 
ues  for  the  AICDM  captures  the  intent — either  stated  by  the  OMSC  or  inferred  by  us — of 
OMSC  values.  Table  6  gives  some  examples  of  inferences.  The  first  column  lists  values 
(i.e.,  data  types)  returned  by  OMSC  methods.  The  second  column  suggests  AICDM  enti¬ 
ties  and  attributes  with  which  these  values  might  align.  The  third  column  gives  issues: 
inferences  and  ambiguities. 

Table  6.  Data  Level  Alignment  Issues 


Value 

Alignment  Possibilities 

Issues 

side 

UnitgetSideO  to  ORGANIZATION 

1  f  we  adopt  the  convention  for  model - 
ing  sides  used  on  p.  38,  there  is  no 
valuefor  ORGANIZATION  TYPE  CODE 
that  ©<plicitly  identifies  an  organiza¬ 
tion  as  denoting  a  coalition  or  faction. 
We  would  need  to  use  either  NOT 
SPECIFIEDorNOTKNOWN. 

Also,  there  is  no  clearly  suitable  value 
for  ORGANIZATION-ASSOCIATION  TYPE 
CODE  in  expressing  a  coalition  or  fac¬ 
tion.  Values  such  as  IS  MOBILIZED  TO 
or  IS  ATTACFIED  TO  might  work  in 
some  ci  rcumstances. 

posture 

UnltgetPostureO  to  ORGANIZATION- 
OPERATIONAL-STATUS  PROTECTIVE 
POSTURE  CODE 

TheAlCDM  postures  seem  restrictive 
in  comparison  to  the  OMSC  postures 

status 

UnltgetStatusO  to  ORGANIZATION- 
OPERATIONAL-STATUS  COMBAT 
EFFECTIVENESS  CODE 

TheAlCDM  status  seems  restrictive 
i  n  comparison  to  the  OM  SC  status 

5.3.5  Degree  of  Alignment 

We  shall  determine  degree  of  alignment  with  respect  to  the  top  3  levels.  The  process  is  to 
work  bottom-up.  Starting  at  the  State  level,  we  assign  to  each  method  a  degree  of  align¬ 
ment.  As  noted  in  Section  4.3.4,  we  assign  a  value  informally,  because  we  lack  Value 
level  analysis  data. 

The  assigned  value  is  a  percentage.  We  opt  to  use  five  values  (more  values  are  difficult  to 
justify).  These  values  are  explained  in  Table  7.  (The  “Standard  Phrase”  column  is  particu- 
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larly  important  in  the  alignment  analysis  in  Appendix  A.  It  relates  the  analysis,  whieh  is 
free  text,  to  the  numerie  value.) 


Table  7.  Possible  Degrees  of  Alignment 


Value 

Standard  Phrase 

Meaning 

0% 

No  alignment 

This  value  is  assigned  in  either  of  the  foil  owing  circum¬ 
stances: 

•  There  is  no  overlap  between  the  models.  One  model 
contains  an  instance  of  an  element  that  has  no  analog  in 
the  other. 

•  Lack  of  information  in  theOMSC  prevents  alignment 
analysis. 

25% 

Low  degree  of  align¬ 
ment 

There  is  some  overlap,  but  it  seems  coincidental.  Overlap 
might  have  been  achieved  by  using  AICDM  attributes  in 
ways  that  its  designers  did  not  originally  intend. 

50% 

Medium  degree  of 
alignment 

Thereis  a  moderate  amount  of  overlap,  but  still  a  signifi¬ 
cant  disconnect  between  the  models. 

75% 

High  degree  of  align¬ 
ment 

Perfect  alignment  can  probably  be  achieved  by  small 
changes  to  one  model  or  the  other. 

100% 

Perfect  alignment 

There  is  an  exact,  unambiguous  mapping  between  the 
models. 

Table  8  shows,  for  eaeh  method,  its  degree  of  alignment  to  the  AICDM.  The  table  gives  a 
rationale  for  eaeh  number.  This  rationale  is  a  summary  of  the  information  in  Appendix  A, 
whieh  fully  deseribes  why  the  value  is  merited.  (Note  that  the  degree  of  alignment  in  the 
first  row  is  not  assigned,  but  ealeulated,  whieh  is  why  it’s  not  one  of  the  values  from  the 
first  eolumn  of  Table  7.) 


Table  8.  State  Level  Degree  of  Alignment 


Method 

%Alignment 

Rationale 

getLocationO 

37% 

The  value  getLocationO  returns  is  represented  by  a  stan¬ 
dard  object  whose  degree  of  alignment  is  calculated 
elsewhere  to  be  37%.  See  Section  6.3. 

getVelocityO 

0% 

The  AICDM  cannot  model  velocity. 

getIDO 

75% 

The  AICDM  has  several  candidate  attributes  for  ID.  A 
unique  mapping  cannot  be  determined. 

getSideO 

75% 

Sides  may  be  modeled  in  the  AICDM  through  organiza¬ 
tion  associations.  However,  if  there  are  more  than  two 
sides,  there  is  no  clear  way  to  express  al  1  possi  ble  combi¬ 
nations  of  friend/foe/neutral  relationships. 

getPostureO 

25% 

The  range  of  values  given  for  the  AICDM  attributes  that 
represent  posture  seems  small  compared  to  the  examples 
given  for  the  OM  SC. 

getStatusO 

25% 

The  range  of  val  ues  given  for  the  AICDM  attri  butes  that 
represent  posture  seems  very  smal  1  compared  to  the  ex¬ 
amples  given  for  the  OM  SC. 

getMissionO 

50% 

An  OM  SC  mission  can  be  mapped  onto  an  Al  CDM 

TASK.  However,  an  AICDM  MISSION  can  bea  complex 
structure  that  cannot  necessarily  be  mapped  onto  an 
OMSC  mission.  At  least,  the  mapping  is  not  reversible. 
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Method 

%Alignment 

Rationale 

getEchelonO 

100% 

The  OMSC  and  the  AICDM  both  model  echelons.  The 
AICDM 's  values  are  a  little  broader,  but  a  given  M&S 
system  can  define  an  exact  mapping. 

moved 

50% 

Some  forms  of  moved  can  be  aligned,  but  some  can't,  de¬ 
pending  on  the  parameter  configurations. 

determineAttritionO 

75% 

determineAttritionO  aligns  indirectly.  It  aligns  to  the  same 
degree  as  the  Attrition. causeAttritiond  method. 

We  calculate  degree  of  alignment  at  the  Entity  level  based  on  this  information.  The  de¬ 
gree  of  alignment  between  the  OMSC  Unit  class  and  the  AICDM  entities  and  relationships 
identified  above  is  the  average  of  the  degrees  of  alignment  of  the  methods  associated  with 
the  Unit  class: 


37-K)4-75-f-754-25-f-25-f-50-f-1004-50-f-75 


The  degree  of  alignment  between  the  Unit  standard  object  and  the  AICDM  Military  Unit 
view  is  calculated  as  the  average  degree  of  alignment  between  classes  in  the  Unit  standard 
object  and  sets  of  AICDM  entities  and  relationships,  in  a  similar  fashion. 

Table  7  uses  a  scale  between  0  and  100  and  provides  for  the  use  of  5  values  on  that  scale. 
To  cover  the  scale  (which  is  necessary  if  calculated  values  like  51%  are  to  be  introduced), 
it  is  necessary  to  interpret  a  value  from  Table  7  as  covering  a  range  of  possible  degrees  of 
alignment,  as  shown  in  Table  9. 

Table  9.  Statistical  Interpretation  of  Degrees  of  Alignment 


Value 

Mean 

Range 

0 

6.25 

0<X<12.5 

25 

25 

12.5<X<37.5 

50 

50 

37.5  <  X  <  62.5 

75 

75 

62.5<X<87.5 

100 

92.75 

87.5<X<100 

Table  9  shows  the  values  25,  50,  and  75  as  mean  ranges  that  cover  ranges  ±12.5.  The  val¬ 
ues  0  and  100  have  means  of  6.25  and  92.75  respectively,  and  cover  ranges  ±6.25,  since 
values  less  than  0  or  greater  than  100  are  not  possible. 

The  meaning  of  the  ranges  is  that  a  method’s  degree  of  alignment  has  some  error.  This 
error  is  due  to  the  coarseness  of  the  scale  in  Table  7.  When  an  analyst  assigns  a  degree  of 
alignment  of  50%  to  a  method,  he  is  really  saying  that  the  degree  of  alignment  is  between 
37.5%  and  62.5%  The  existence  of  this  error  implies  that  the  value  of  51%  computed  for 
the  Unit  class  has  some  error.  However,  we  can  estimate  that  error  by  making  the  follow¬ 
ing  assumptions: 

•  Errors  are  uncorrelated. 

•  The  errors  in  selecting  a  value  from  within  a  range  are  normally  distributed. 

These  assumptions  are  not  strictly  true  (see  Appendix  A),  but  the  sample  sizes  used  in  the 
calculations  in  Section  6  and  Appendix  A  are  large  enough  that  the  effect  shouldn’t  mat¬ 
ter. 
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The  central  limit  theorem  of  statistics  says  that  whenever  a  random  sample  of  size  n  with 
mean  p  and  variance  cr^  is  taken  from  a  distribution,  the  sample  mean  Xn  has  a  distribu¬ 
tion  that  is  approximately  normal  with  mean  p  and  variance  a^jn .  In  other  words,  the 
variance  (and  hence  the  standard  deviation)  is  inversely  proportional  to  the  sample  size. 

The  second  assumption  means  the  standard  deviation  for  a  range  r  is  r/Vs  .  Therefore,  the 
standard  deviation  is  6.5/V3  for  alignment  values  0  and  100,  and  12.5/73  for  25,  50,  and 
75.  The  standard  deviation  for  the  Location  standard  object  is  3.61  (see  Section  6.3),  so 
the  standard  deviation  for  the  error  in  the  degree  of  alignment  of  the  Unit  class  is: 

3.61  +  2x(6.25/V3)+7x(l2.5/V3)_  ^ 

H) 

In  other  words,  the  probability  that  the  degree  of  alignment  of  the  Unit  class  is  between 
45%  and  57%  (within  1  standard  deviation  of  the  mean)  is  about  68%. 

This  analysis  describes  the  error  a  single  analyst  can  make  in  calculating  degree  of 
alignment.  Since  the  assignment  of  values  at  the  State  level  has  inherent  subjectivity,  two 
analysts  might  assign  the  same  method  different  degrees  of  alignment.  The  assumptions 
made  to  compute  error  cover  estimating  error  only. 
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6.  Results  of  Apply!  ng  the  Model 


This  section  presents  the  results  of  assessing  alignment  between  the  AICDM  and  the 
OMSC  using  the  process  described  in  Section  5:  a  calculation  of  the  degree  of  alignment 
between  the  AICDM  and  the  OMSC  for  each  standard  object  in  the  OMSC.  Briefly,  these 
results  are  as  follows: 


Table  10.  Standard  Object  Degrees  of  Alignment 


Standard  Object 

Degree  of  Alignment  to  the 
AICDM 

Unit 

56% 

Piatform 

55% 

Location 

37% 

Degree  of  alignment  is  calculated  with  respect  to  the  Conceptual,  Entity,  and  State  levels: 

For  each  standard  object: 

For  each  class  in  the  standard  object: 

For  each  method  in  the  class: 

•  If  the  analysis  for  the  method  in  Appendix  A  indicates  the  method 
aligns  to  attributes  (directly  or  indirectly),  then  estimate  the  method’s 
degree  of  alignment  to  those  attributes. 

•  If  the  analysis  indicates  the  method  aligns  to  an  AICDM  entity  or 
view,  use  the  degree  of  alignment  calculated  for  that  entity  or  view. 

Compute  the  class’  degree  of  alignment  as  the  average  of  the  degrees  of 
alignment  of  all  methods  in  the  class. 

Compute  the  standard  object’s  degree  of  alignment  as  the  average  of  the  degrees 
of  alignment  of  all  classes  in  the  standard  object. 

Each  standard  object  has  a  separate  section.  Each  class  within  a  standard  object  has  a 
subsection.  Within  that  subsection  is  a  table  giving  degrees  of  alignment  for  all  the  class’ 
methods.  The  table  explains  the  rationale  for  the  estimated  degree  of  alignment.  The  ra¬ 
tionale  is  a  summary  of  the  materiel  on  the  method  in  Appendix  A. 

The  OMSC  shares  classes  among  standard  objects  (e.g..  Communications).  For  a  shared 
class,  the  degree  of  alignment  calculation  is  presented  once,  then  referenced  for  other 
uses  of  the  class. 

The  error  can  be  computed  for  each  class  (see  p.  43).  But  some  classes  contain  only  one 
or  two  methods,  and  error  computations  would  be  suspect.  It  makes  more  sense  to  com¬ 
pute  the  error  for  an  entire  standard  object.  These  values  are  given  at  the  end  of  each 
standard  object’s  subsection. 


45 


6.1  Unit  Standard  Object 

6.1.1  Unit  Class 


Method 

% 

Rationale 

getLocationO 

37%7 

(See  Section  Ofor  the  derivation  of  this  degree  of  alignment) 

qetVelocityO 

0% 

TheAlCDM  cannot  model  velocity. 

getIDO 

75% 

TheAlCDM  has  several  candidate  attributes  for  ID.  A  unique 
mapping  cannot  be  determined,  however. 

getSideO 

75% 

Sides  may  be  modeled  in  theAlCDM  through  organization  asso¬ 
ciations.  However,  if  there  are  more  than  two  sides,  thereis  no 
clear  way  to  express  all  possible  combinations  of 
friend/foe/neutral  relationships. 

getPostureO 

25% 

The  range  of  values  given  for  theAlCDM  attributes  that  repre¬ 
sent  posture  seems  small  compared  to  the  examples  given  for  the 
OMSC. 

getStatusO 

25% 

The  range  of  val  ues  given  for  the  Al  CDM  attri  butes  that  repre¬ 
sent  posture  seems  very  small  compared  to  the  examples  given 
for  the  OMSC. 

getMissionO 

50% 

An  OMSC  mission  can  be  mapped  onto  an  AlCDM  TASK.  How¬ 
ever,  an  AlCDM  MISSION  can  be  a  complex  structure  that  cannot 
necessarily  be  mapped  onto  an  OMSC  mission.  At  least,  the  map¬ 
ping  is  not  reversible. 

getEchelonO 

100% 

The  OM  SC  and  the  Al  CDM  both  model  echelons.  The  Al  CDM 's 
values  are  a  little  broader,  but  a  given  M&S  system  can  define  an 
exact  mapping. 

moved 

50% 

Some  forms  of  moved  can  be  aligned,  but  some  can't,  depending 
on  the  parameter  configurations. 

determineAttritionO 

75% 

determineAttritionO  aligns  indirectly.  It  aligns  to  the  same  degree  as 
the  Attrition. causeAttritionO  method. 

51%  Unit  class  Degree  of  Alignment 


6.1.2  UnitGeometry  Class 


Method 

% 

Rationale 

getShaped 

100% 

TheAlCDM  can  model  arbitrary  polygons,  and  seems  to  have  an 
adequate  model  of  three-dimensional  entities. 

getOrientationO 

0% 

TheAlCDM  does  not  model  orientation. 

50% 


UnitGeometry  class  Degree  of  Alignment 


^  This  and  some  other  numbers  are  in  italics  to  indieate  that  they  are  not  drawn  from  Table  7,  but  calcu¬ 
lated  as  the  degree  of  alignment  of  some  other  entity. 
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6.1.3  Intel  Class 


Method 

% 

Rationale 

collectO 

0% 

Nothing  about  how  the  collectO  method  aligns  to  the  AICDM  can 
be  determi  ned  at  the  State  1  evel . 

reportContactsO 

75% 

A  contact  is  probably  a  battlefield  entity  (FEATURE,  PERSON, 
MATERIEL,  ORGANIZATION,  or  FACILITY),  but  the  OMSC  does  not  pro¬ 
vide  details. 

37% 


Intel  class  Degree  of  Alignment 


6.1.4  Communications  Class 


Method 

% 

Rationale 

getNetO 

100% 

The  AICDM  can  model  objects  capable  of  exchanging  messages, 
which  is  all  that  must  be  returned  or  set  by  these  methods. 

setNetO 

75% 

The  AICDM  can  model  more  types  of  communications  networks 
than  the  OMSC. 

sendMessageO 

75% 

The  content  of  a  message  can  be  modeled  as  an  INFORMATION- 
REFERENCE,  and  the  act  can  be  modeled  through  theAlCDM 
ACTION  entities.  However,  theAlCDM  lacks  attribute  values  to 
model  sending  or  receiving  messages. 

receiveMessageO 

75% 

81% 


Communications  class  Degree  of  Alignment 


6.1.5  SystemG roup  Class 


Method 

% 

Rationale 

getOtyO 

100% 

These  methods'  return  values  have  exact  counterparts  in  AICDM 
attributes. 

acceptLossesO 

100% 

acceptOainsO 

100% 

100% 


SystemGroup  class  Degree  of  Alignment 


6.1.6  Platform  Class 

This  class  is  modeled  by  an  OMSC  standard  objeet.  See  Seetion  6.2. 


55% 


Platform  class  Degree  of  Alignment 


6.1.7  Platforminfo  Class 

The  description  of  the  Platforminfo  class  indicates  that  it  returns  static  properties  of  entities. 
The  AICDM  models  very  few  statie  properties  of  entities. 


25% 


Platforminfo  class  Degree  of  Alignment 
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6.1.8  Attrition  Class 


Method 

% 

Rationale 

causeAttritionO 

75% 

TheAlCDM's  model  accounts  for  both  changes  in  associations 
among  entities  and  for  holdings  of  materiel  and  personnel  types. 
However,  if  the  attrition  is  ©(pressed  as  holdings,  theAlCDM 
can  only  model  loss.  Its  model  of  degradation  is  poor. 

75% 


Attrition  class  Degree  of  Alignment 


6.1.9  Logistics  Class 


Method 

% 

Rationale 

received 

75% 

The  attributes  used  to  record  logistics  information  area  subset  of 
those  used  to  determine  attrition.  Si  nee  the  Attrition  class  aligns 

75%  with  theAlCDM,  the  received  method  must  align  75%t(X). 

75% 


Logistics  class  Degree  of  Alignment 


6.1.10 Maintenance  Class 


Method 

% 

Rationale 

conductMaintenanced 

25% 

TheAlCDM  attributes  that  record  operational  status  of  a  per¬ 
son  or  materiel  item  do  not  fully  capture  the  meaning  of  what 
is  expressed  by  this  operation. 

conductEvacuationO 

50% 

The  MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE  and 
PERSON-TYPE-ORGANIZATION-HOLDING-ESTIMATE  entities  rep¬ 
resent  the  number  of  materiel  items  and  personnel  assexiated 
with  an  ORGANIZATION.  However,  these  entities  have  no  rela¬ 
tionships  to  theLOCATION  entity,  which  models  the  Icxation  of 
an  entity.  This  would  be  a  problem  if  only  part  of  an  organiza¬ 
tion  were  evacuated.  (One  strategy  for  modeling  evacuation 
would  betocreatea  new  ORGANIZATION  for  each  group  of 
evacuated  personnel  and  equipment.) 

The  MATERIEL  entity  has  a  many-to-many  relationship  with 
LOCATION  and  with  ORGANIZATION.  However,  MATERIEL  models 
individual  materiel  items,  not  types. 

conductRecoveryO 

50% 

42% 


Maintenance  class  Degree  of  Alignment 
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6.1.11Supply  Class 


Method 

% 

Rationale 

getRemainingCapacityO 

75% 

This  method  aligns  indirectly.  Its  degree  of  alignment  is  the 
minimum  of  thoseof  getTotaiCapactityO  and  getQtyOnHandO. 

getTotalCapacityO 

75% 

The  AlCDM  can  model  total  capacity  by  relating  a 

CAPABILITY  entity  to  an  ORGANIZATION  via  ORGANIZATION- 
CAPABILITY-ESTIMATE  or  ORGANIZATION-TYPE-CAPABILITY- 
NORM.  However,  the  values  of  theCAPABILITY  TYPE  CODE 
attri  bute  are  i  nadequate. 

getQtyOnHandO 

75% 

This  method  aligns  only  if  its  result  is  an  ordinal  value.  If  it 
is  measured  in  other  units,  the  AlCDM  has  no  attributes 
that  align. 

expendO 

75% 

These  methods  align  to  the  same  degree  that  getQtyOnHandO 
does. 

transfer!) 

75% 

75% 


Supply  class  Degree  of  Alignment 


6.1.12C2Class 


Method 

% 

Rationale 

doC20 

0% 

Nothing  about  alignment  can  be  determined. 

0% 


C2  class  Degree  of  Alignment 


6.1.13 Unit  Standard  Object  Degree  of  Alignment 

The  degree  of  alignment  for  the  Unit  standard  objeet  is  the  average  of  the  degrees  of 
alignment  of  the  elasses  it  eontains: 

51+50+37  481+100+55+25+75+75+42+7540 

- -  =56% 

12 

The  error  in  the  degree  of  alignment  is: 

4  +  6  +  10x(625/V3)+22x(l2.5/V3)_  ^ 

34 

(4  and  6  represent  the  errors  from  the  Loeation  and  Platform  standard  objeets,  respee- 
tively.  The  Unit  standard  objeet  eontains  10  methods  whose  degrees  of  alignment  are  as¬ 
signed  either  0  or  100  and  therefore  have  a  standard  deviation  of  6.25/ Vs.  The  other  22 
methods  have  a  standard  deviation  of  12.5/V3  .) 
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6.2  Platform  Standard  Object 

6.2.1  Platform  Class 


Method 

% 

Rationale 

getTypeO 

75% 

TheOMSC  is  vague  about  type.  The  analysis  has  indicated  that 
some  types  can  be  modeled,  but  it  is  unrealistic  to  expect  that  all 
can. 

getStatusO 

100% 

TheOMSC  examples  of  status  for  platforms  are  considerably 
simpler  than  for  units.  In  this  case,  the  Al  COM  attributes  appear 
adequate. 

qetLocationO 

37% 

See  the  description  of  getLocationO  in  Section  6.1.1. 

getSideO 

75% 

See  the  description  of  getSided  in  Section  6.1.1. 

assessDamageO 

25% 

The  Al  COM  does  not  have  attri  butes  designed  to  assess  damage. 
The  analysis  found  a  few  attributes  whose  domains  can  designate 
certain  broad  classes  of  damage. 

62% 

Platform  class  Degree  of  Alignment 

6.2.2  Sensor  Class 

Method 

% 

Rationale 

getMaxRangeO 

100% 

This  method  aligns  exactly  to  an  AlCDM  attribute. 

getOrientationO 

0% 

The  Al  COM  does  not  model  orientation. 

getContactsO 

50% 

The  vagueness  of  the  OM  SC  description  of  the  method  leaves 
open  the  possibility  that  this  method  returns  information  the 
AlCDM  cannot  mcxdel. 

activated 

0% 

AlCDM  attribute  values  apparently  model  capability  to  operate 

deactivated 

0% 

rather  than  operation. 

30% 


Sensor  class  Degree  of  Alignment 


6.2.3  Weapon  Class 


Method 

% 

Rationale 

getMaxRangeO 

100% 

This  method  aligns  exactly  to  an  AlCDM  attribute. 

loadd 

0% 

The  AlCDM  does  not  model  whether  a  weapon  is  loaded. 

engageTargetd 

50% 

The  Al  CDM  does  not  model  properties  of  a  weapon  related  to  tar¬ 
get  engagement. 

50% 


Weapon  class  Degree  of  Alignment 
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6.2.4  Movement  Class 


Method 

% 

Rationale 

getVeiocityO 

0% 

TheAlCDM  does  not  model  velocity. 

changeVeiocityO 

0% 

moveToO 

75% 

At  least  some  forms  of  movement  can  be  modeled,  probably  more 
than  for  a  unit  (see  the  description  of  moved  in  Section  6.1.1). 

25% 


Movement  class  Degree  of  Alignment 


6.2.5  Logistics  Class 


The  degree  of  alignment  of  the  Logistics  class  is  equal  to  the  degree  of  alignment  of  the 
Logistics  class  in  the  Unit  standard  object.  See  Section  0. 


75% 


Logistics  class  Degree  of  Alignment 


6.2.6  Supply  Class 


The  degree  of  alignment  of  the  Suppiy  class  is  equal  to  the  degree  of  alignment  of  the 
Suppiy  class  in  the  Unit  standard  object. 


75% 


Supply  class  Degree  of  Alignment 


6.2.7  Maintenance  Class 


Method 

% 

Rationale 

conductMaintenanceO 

25% 

TheAlCDM  attributes  that  record  operational  status  of  a  per¬ 
son  or  materiel  item  do  not  fully  capture  the  meaning  of  what 
is  expressed  by  this  operation. 

25% 


Maintenance  class  Degree  of  Alignment 


6.2.8  Crew  Class 


Method 

% 

Rationale 

getQuantityO 

100% 

This  method  is  modeled  either  by  direct  relationships  or  by 
HOLDING  entities. 

100% 


Crew  class  Degree  of  Alignment 


6.2.9  Communications  Class 


The  degree  of  alignment  of  the  Communications  class  is  equal  to  the  degree  of  alignment  of 
the  Communications  class  in  the  Unit  standard  object.  See  Section  0. 


81% 


Communications  class  Degree  of  Alignment 
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6.2.10Carrier  Class 


Method 

% 

Rationale 

loadO 

100% 

These  methods  are  modeled  either  by  direct  relationships  or 
by  HOLDING  entities. 

unloadO 

100% 

getRemainingCapacityO 

75% 

This  method  aligns  indirectly.  Its  degree  of  alignment  is  the 
minimum  of  that  of  getTotalCapacityO  and  getQtyOnHandO. 

getTotalCapacityO 

75% 

See  Section  0. 

getQtyOnHandO 

75% 

See  Section  0. 

85% 


Carrier  class  Degree  of  Alignment 


6.2.11  PlatformF  rame  C  lass 


Method 

% 

Rationale 

gets  ig  nature!) 

25% 

The  AICDM  can  model  a  very  limited  range  of  signature  types. 

25% 


PlatformFrame  class  Degree  of  Alignment 


6.2.12  FrameComponent  Class 


Method 

% 

Rationale 

gets  ig  nature!) 

25% 

The  AICDM  can  model  a  very  limited  range  of  signature  types. 

25% 


FrameComponent  class  Degree  of  Alignment 


6.2. 13  Platform  Standard  Object  Degree  of  Alignment 

The  degree  of  alignment  of  the  Platform  standard  objeet  to  the  AICDM  is  the  average  of 
the  degrees  of  alignment  of  its  elasses: 

62+30+50+25+75+75+25+100+81+85+25+25 

“  55% 

12 

The  error  in  the  degree  of  alignment  is: 

4  +  13x(6.25/V3)+21x(i2.5/V3)  _  ^ 

35 

(4  represents  the  error  from  the  Loeation  standard  objeet.  The  Platform  standard  objeet 
eontains  13  methods  whose  degrees  of  alignment  are  assigned  either  0  or  100  and  there¬ 
fore  have  a  standard  deviation  of  6.25/ V3  .  The  other  21  methods  have  a  standard  devia¬ 
tion  of  12.5/V3  .) 
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6.3  Location  Standard  Object 

6.3.1  Location  Class 


Method 

% 

Rationale 

distanceFromO 

25% 

Two  factors  determine  the  degree  of  alignment: 

•  The  AICDM  models  geodetic  but  not  Cartesian  coordinates. 

•  The  AICDM  can  model  the  method's  inputs  (two  locations)  but 
not  its  result;  that  is,  the  AICDM  does  not  model  distances. 

convertO 

50% 

The  AICDM  models  geodetic  but  not  Cartesian  coordinates.  In 
other  words,  for  a  given  invocation,  it  can  model  the  method's 
input  but  not  the  output,  or  viceversa.^ 

37% 

Location  class  Degree  of  Alignment 

6.3.2  Local  Cl 

lass 

Method 

% 

Rationale 

qetXCoordinateO 

0% 

The  AICDM  does  not  model  local  coordinate  systems. 

qetY  Coordinated 

0% 

qetZCoordinateO 

0% 

0% 


Local  class  Degree  of  Alignment 


6.3.3  LatLon  Class 


Method 

% 

Rationale 

qetLatitudeO 

75% 

The  precision  for  latitudes  and  longitudes  differs  between  the 

AICDM  and  the  OMSC. 

qetLonqitudeO 

75% 

qetAltitudeO 

75% 

The  Al  CDM  can  specify  altitudes  to  vary!  ng  degrees  of  precision. 
Moreover,  the  AICDM  uses  the  metric  system,  and  the  OMSC  uses 
the  English  system.  This  can  cause  some  minor  errors  in  conversion. 

75% 


LatLon  class  Degree  of  Alignment 


Many  simulation  systems  convert  between  Cartesian  and  geodetic  coordinates.  Arguably,  then,  the 
degree  of  alignment  for  convert()  should  be  higher.  However,  there  are  many  competing  models  for 
eonverting  between  coordinate  systems,  depending  on  sueh  factors  as  line-of-sight  computation  needs. 
The  AICDM  and  the  OMSC  are  intended  as  domain  standards.  Since  standards  in  coordinate  conver¬ 
sion  have  not  emerged,  it  seems  safest  to  assume  coordinate  conversion  can’t  be  automated. 
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6.3.4  Location  Standard  Object  Degree  of  Alignment 

The  degree  of  alignment  of  the  Location  standard  object  to  the  AICDM  is  the  average  of 
the  degrees  of  alignment  of  its  classes: 


3740+75 

3 


=  37% 


The  error  in  the  degree  of  alignment  is: 


3 X  (6.25/V3 )+  5 X  (l 2.5/V3 )  _  ^ 
8 


(The  Location  standard  object  contains  3  methods  whose  degrees  of  alignment  are  as¬ 
signed  either  0  or  100  and  therefore  have  a  standard  deviation  of  6.25/ Vs  .  The  other  5 
methods  have  a  standard  deviation  of  12.5/V3  .) 
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7.  Recommendations 


The  analysis  has  led  to  reeommendations  on  what  must  be  done  if  the  AICDM  and  the 
OMSC  are  to  be  brought  into  alignment.  These  are  reeommendations  for  ehanges  to  the 
AICDM  and  to  the  OMSC. 

Some  of  the  reeommendations  are  straightforward  and  narrow  in  seope,  affeeting  a  small 
portion  of  one  or  the  other  model.  (An  example  would  be  to  add  a  value  to  an  AICDM 
attribute’s  domain.)  These  reeommendations  are  enumerated  in  Seetion  7.1. 

A  few  of  the  reeommendations  are  broader.  They  argue  for  a  philosophieal  shift  to  a 
model.  They  elaim  that  in  sueh  things  as  the  type  of  entities  modeled  or  the  nature  of  how 
entities  are  modeled,  either  the  AICDM  or  the  OMSC  (or  perhaps  both)  are  ineomplete  as 
regards  alignment.  A  reeommendation  of  this  sort  elearly  needs  justifieation.  Seetion  7.2 
presents  the  broader  set  of  reeommendations,  and  argues  for  their  importanee  in  aehiev- 
ing  alignment. 

7.1  Specific  Recommendations 

This  seetion  presents  speeifie  reeommendations  for  ehanges  to  the  AICDM  and  the 
OMSC.  Eaeh  ehange  is  intended  to  promote  alignment.  The  materiel  is  organized  aeeord- 
ing  to  standard  objeets,  elasses  within  standard  objeets,  and  methods  within  elasses.  For 
eaeh  method,  a  table  presents  issues  driving  the  reeommendations,  and  the  reeommenda¬ 
tions  themselves. 

The  reeommendations  for  the  AICDM  and  the  OMSC  are  split  into  separate  seetions  to 
promote  an  understanding  of  the  ehanges  suggested  for  eaeh  method.  Appendix  D  pre¬ 
sents  the  ehanges  grouped  by  standard  objeets,  elasses  within  standard  objeets,  and  meth¬ 
ods  within  elasses.  For  eaeh  method,  a  table  presents  issues  driving  the  reeommendations, 
and  the  reeommendations  themselves.  This  helps  the  reader  see  how  alignment  issues 
jointly  drive  ehanges  to  eaeh  model. 

The  material  in  this  seetion  is  intended  as  preliminary.  Further  study  is  needed  to  deter¬ 
mine  the  utility  and  form  of  eaeh  reeommendation. 


7.1.1  Recommended  C  hanges  to  the  Al  C  DM 


Method  Issues 

Recommendations 

Unit  Standard  Object 

The  Unit  Class 

gelVelocityO 

The  AICDM  does  not  model 
velocity. 

The  AICDM  needs  to  be  able  to  model 
the  velocity  of  (at  least)  the  PERSON, 
MATERIEL,  and  ORGANIZATION  entities. 
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Method 

Issues 

Recommendations 

getSideO 

TheAlCDM  does  not  have 
an  explicit  model  of  sides, 
although  one  can  be  simu¬ 
lated  using  ORGANIZATION 
structures. 

TheAlCDM  should  enhance  its  ability 
to  model  friends  and  foes.  One  ap¬ 
proach  is  to  add  values  FACTION  and 
COALITION  to  the  IDENTIFICATION-FRIEND- 
FOE  CODE  attribute  of  the 

ORGANIZATION  entity.  Another  is  to  ex¬ 
ternalize  the  FRIEND-FOE  attributes. 

getPostureO 

TheAlCDM  has  a  limited 
set  of  attributes  that  can 
represent  posture.  Their 
val  ues  do  not  cover  the  ex¬ 
amples  of  status  given  in  the 
OMSC. 

The  Al  CDM  needs  to  add  an  attri  bute 
associated  with  an  ORGANIZATION  that 
can  represent  posture.  Si  nee  different 
types  of  organizations  can  have  differ¬ 
ent  types  of  posture  (e.g.,  a  civilian 
organization  will  not  have  the  same 
types  of  a  posture  as  a  military  or¬ 
ganization),  it  might  make  sense  to 
have  multi  pie  posture  attributes,  each 
associated  with  a  subtype  of 
ORGANIZATION. 

getStatusO 

TheAlCDM  has  a  very  lim¬ 
ited  set  of  attributes  that 
can  represent  status.  Their 
val  ues  do  not  cover  the  ex¬ 
amples  of  status  given  in  the 
OMSC. 

Necessary  changes  to  the  Al  CDM 
cannot  be  determined  until  the  con¬ 
cept  of  status  in  M&S  systems  is  bet¬ 
ter  understood.  However,  it  is  likely 
that: 

•  TheAlCDM  will  need  to 
accommodate  numeric  descriptions 
of  status  (e.g.,  as  percent 
effectiveness). 

•  TheAlCDM  will  need  additional 
codes. 

The  UnitGeometry  Class 

getO  rientationO 

TheAlCDM  does  not  model 
orientation. 

TheAlCDM  should  include  informa¬ 
tion  on  orientation.  It  is  likely  that 
orientation  must  be  specified  for  sev¬ 
eral  types  of  entities  (organizations 
and  platforms,  at  least).  Given  the  at¬ 
tributes  of  POINT,  which  include  preci¬ 
sion,  it  is  probably  necessary  to  create 
a  new  entity,  ORIENTATION,  containing 
attributes  that  express  orientation. 

1  nstances  of  this  entity  would  be 
linked  to  an  ORGANIZATION  (or 

PLATFORM)  through  a  many-to-many 
relationship  via  an  intermediate 
ORGANIZATION-ORIENTATION  entity  (simi¬ 
lar  to  the  relationship  between 
ORGANIZATION  and  LOCATION).  An  orien¬ 
tation  may  beabsoluteor  relative 
(e.g.,  "in  front  of"),  and  the  Al  CDM 
should  be  ableto  model  both  types. 
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Method 

Issues 

Recommendations 

The  Supply  Class 

•  getRemainingCapacityO 

•  getTotalCapacityO 

•  transferO 

The  Al  COM  does  not  model 
capacity 

TheAlCDM  needs  entities  that  model 
capacity. 

The  Maintenance  Class 

conductMaintenanceO 

TheAlCDM  does  not  have 
an  attribute  of  ACTION  that 
can  record  maintenance. 

A  new  value,  CONDUCT  MAINTENANCE, 
needs  to  be  added  to  the  action-verb 

CODE  attribute  of  ACTION. 

The  Intel  Class 

collectO 

TheAlCDM  does  not  model 
sensor  activation  and  deac¬ 
tivation. 

TheAlCDM  needs  attributes  that  give 
the  state  of  a  sensor,  as  wel  1  as  other 
possi  ble  sensor-specific  characteristics 
(e.g.,  orientation) 

reportContactsO 

Typically,  M&S  systems  can 
model  any  entity  detected  by 
intelligence.  TheAlCDM 
can  only  record  such  an  en¬ 
tity  if  it  is  a  candidate  tar¬ 
get. 

•  TheAlCDM  needs  to  model  entities 
recorded  by  intelligence  but  not  yet 
known  to  be  (candidate)  targets. 

•  The  codes  associated  with  feature 
need  to  account  for  intelligence. 

•  The  proposed  AlC DM  entity 
INFORMATION-REFERENCE  maybe 
useful  for  modeling  intelligence 
results.  The  domain  values  of  the 
INFORMATION-REFERENCE-CATEGORY- 
CODE  attribute  would  need  to  be 
extended  to  account  for  i  ntel  1  igence. 

Platform  Standard  Object 

The  Platform  Class 

getTypeO 

For  convenience,  the  AlCDM  may 
need  to  be  amended  to  include  a  new 
entity  class  PLATFORM.  Subtypes  of  this 
entity  would  include  all  AlCDM  enti¬ 
ties  that  are  considered  platforms  in 
TheOMSC.  (TheDDA  contains  sepa¬ 
rate  entities  for  ships  and  satellites. 

We  recommend  including  these  enti¬ 
ties  in  the  AlCDM  to  address  M&S 
requirements  for  water  and  space 
platforms.) 

assessDamageO 

TheAlCDM  codes  for  dam¬ 
age  to  materiel,  facilities, 
and  people  are  not  adequate 
to  model  the  types  of  dam¬ 
age  possi ble  i n  an  M  S(S  sys¬ 
tem. 

TheAlCDM  needs  codes  for  materiel, 
facilities,  and  peoplethat  model  the 
types  of  damage  possi  ble  to  such  enti¬ 
ties  in  M&S  systems. 

Possi  bly  some  types  of  damage  are 
complex  enough  to  warrant  creation  of 
a  new  entity,  with  attributes  to  model 
the  vari  ous  types  of  damage. 

The  Sensor  Class 

•  activated 

•  deactivated 

TheAlCDM  does  not  model 
whether  a  sensor  is  on  or  off. 

TheAlCDM  needs  to  model  sensor 
state. 
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Method 

Issues 

Recommendations 

The  Weapon  Class 

loadO 

TheAlCDM  does  not  model 
whether  or  not  a  weapon  is 
loaded. 

TheAlCDM  needs  to  be  able  to  model 
the  state  of  a  weapon. 

engageTargetO 

TheAlCDM  does  not  model 
weapon  firing. 

TheAlCDM  needs  to  model  weapon 
firing.  More  precisely,  it  needs  to 
model  the  status  of  a  weapon,  includ¬ 
ing  being  in  a  firing  state  (whatever 
that  might  mean  for  a  particular 
weapon). 

The  PlatformFrame  Class 

getSignatureO 

TheAlCDM  can  model  only 
a  cross-sectional  area  signa¬ 
ture. 

TheAlCDM  should  increase  the  range 
of  signatures  that  it  can  model.  (The 
DDA  has  attributes  to  keep  track  of 
height,  weight,  etc,  that  the  Al  CDM 
lacks.) 
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7.1.2  Recommended  Changes  to  the  OMSC 


Method  Issue 

Recommendations 

The  Unit  Standard  Object 

The  Unit  Class 

getLocationO 

•  The  OMSC  is  ambiguous 
about  how  a  unit  location 
is  modeled.  It  says: 

Typically  [current 
unit  location]  is 
the  center  of  mass 
or  some  other 
point  location  rep¬ 
resentative  of  the 
unit  location. 

If  center  of  mass  is  typi¬ 
cal  ,  there  must  be  some 
atypical  representations. 
The  OM  SC  does  not 
enumerate  them. 

•  The  OMSC  does  not  define 
how  center  of  mass  is 
computed.  M&S 
applications  use  different 
models  that  depend  upon 
factors  such  as  level  of 
aggregation  (corps/division 
vs.  theater)  and  whether 
the  simulation  is  for 
training  or  analytical 
purposes.  (1  n  some  M  S(S 
training  applications, 
center  of  mass  is  not 
computed  at  all,  but  is 
estimated  by  (and  entered 
by)  a  human  operator.) 

•  The  OMSC  should  enumerate  all 
valid  ways  in  which  a  unit's  location 
can  be  modeled.  A  better  approach 
would  be  to  accept  center  of  mass  as 
the  standard  way  to  represent 
location.  Other  location-like 
quantities  (e.g.,  areas)  should  be 
represented  using  other  classes. 

•  The  Location  class  should  have  a 
virtual  method centerOfMassO.  An 

M&S  application  based  on  the 

OM  SC  would  need  to  supply  a 
definition  for  the  method. 

gelVelocityO 

The  OM  SC's  description 
does  not  prescribe  the  units 
in  which  velocity  compo¬ 
nents  are  expressed. 

The  OMSC  should  define  a  (param¬ 
eterized)  model  of  velocity.  The  model 
must  describe  units  and  degree  of  pre¬ 
cision  (or  these  quantities  must  be  pa¬ 
rameters). 

getIDO 

The  OMSC  does  not  indicate 
how  the  1 D  might  be  used. 
Use  can  prescribe  format. 
(E.g.,  if  an  1 D  labels  units  on 
a  screen,  it  must  be  short.) 
This  infl uences  whether  the 
AlCDM  can  model  OMSC 

1  Ds  using  existing  attrib¬ 
utes. 

The  OMSC  should  define  a  model  of 

1  Ds  based  on  their  use  in  existing 

M&S  systems.  Ideally,  the  OMSC 
should  use C4I  IDs. 
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Method 

Issue 

Recommendations 

getSideO 

•  TheOMSC  does  not 
indicate  the  maximum 
number  of  sides  that  must 
be  supported.  At  onetime 
it  was  assumed  that  the 
only  sides  would  be  "blue" 
and  "red",  but  with  the 
advent  of  coalition  warfare 
the  number  of  possible 
sides  has  grown.  Note  that 
WARSIM  has  a 
contractual  requirement 
to  support  at  least  36 
different  sides. 

•  TheOMSC  states  that 
there  is  no  implied  enmity 
between  sides,  but  does 
not  state  the  possi  bl  e 
relationships  between 
sides. 

•  TheOMSC  should  stateexplicitly 
whether  there  is  an  implied 
maximum  number  of  sides. 

•  TheOMSC  should  enumerate  the 
possible  relationships  between  sides. 

getPostureO 

•  TheOMSC  does  not 
enumerate  all  possible 
postures. 

•  TheOMSC  does  not  relate 
postures  to  other  objects. 

For  instance,  a  posture 
such  as  "hasty  defense" 
implies  that  a  unit's 
velocity  is  zero. 

•  The  OM  SC  needs  to  clarify  the  role 
that  postures  play  in  simulations 
and  the  possible  values  they  may 
have.  Do  they  need  to  be 
distinguished  from  current 
activities,  as  elaborated  by  the 
current  activity  codes  of  the 
ORGANIZATION  and  MILITARY-UNIT 
entities? 

•  Whatever  a  posture  may  be,  the  set 
of  valid  postures  for  a  given  M&S 
system  can  apparently  be  expressed 
as  an  enumeration.  This  suggests 
what  the  result  of  u.getPostureO 
should  be  for  some  unit  u. 

getStatusO 

TheOMSC  does  not  enu¬ 
merate  the  different  types  of 
status. 

TheOMSC  should  define  a  virtual 
cl  ass  S  tatus.  Su  bcl  asses  of  S  tatus 
would  exist  for  every  entity  that  needs 
to  record  status.  Subclass  methods 
would  record  and  provide  different 
facets  of  status  as  appropriate  to  the 
entity. 

getMissionO 

TheOMSC  gives  no  struc¬ 
ture  to  a  mission  or  task.  A 
mission  is  only  free  text. 

The  Al COM,  by  contrast, 
has  a  rich  structure  that  the 
OMSC  cannot  model. 

TheOMSC  should  define  a  Mission 
standard  object  that  provides  a  more 
precise  specification  of  what  tasks  are 
and  how  they  wi  1 1  be  used. 
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Method 

Issue 

Recommendations 

moveO 

•  TheOMSC  does  not  state 
the  parameters  of  the 
method.  Potential 
parameters  include: 

•  New  coordinates  (either 
relative  or  absolute) 

•  Time  until  new 
coordinates  are  reached 

•  The  specification  does 
not  state  whether  the 
next  location  is  known  in 
advance  (in  which  case 
parameters  might  not  be 
needed). 

•  TheOMSC  does  not 
describe  necessary 
granularity  of  movement 
(that  is,  minimum  length 
or  ti  me  of  movement). 

TheOMSC  should  included  a  param¬ 
eterized  model  of  movement,  one  that 
addresses  granularity. 

determineAttritionO 

TheOMSC  does  not  specify 
units  for  attrition  (percent¬ 
age?  absol  ute  val  ues?  spe¬ 
cific  entities  removed?) 

TheOMSC  should  specify  ways  in 
which  attrition  may  be  stated.  Where 
applicable,  the  OMSC  should  specify 
units  and  precision  for  attrition. 

The  UnitGeometry  Class 

getShapeO 

TheOMSC  does  not  indicate 
the  nature  or  generality  of 
bounding  shapes. 

TheOMSC  should  define  the  result  of 
getShapeO  to  be  a  class  Shape.  Shape 
should  have  subclasses  such  as  Rec¬ 
tangle,  Circle,  etc.  This  structure  will 
support  current  needs  while  providing 
for  future  enhancements. 

getO  rientationO 

The  OMSC  does  not  state 
the  units  of  orientation.  Pre¬ 
sumably  orientation  is  in 
degrees. 

The  OM  SC  should  state  the  units  and 
precision  of  orientation. 

The  Supply  Class 

•  getRemainingCapacityO 

•  getTotalCapacityO 

•  transferO 

TheOMSC  does  not  pre¬ 
scribe  how  capacity  is  ex¬ 
pressed. 

TheOMSC  needs  a  standard  model,  or 
perhaps  set  of  models,  for  expressing 
capacity. 

The  Maintenance  Class 

conductMaintenanceO 

•  TheOMSC  does  not 
specify  how  maintenance 
actions  or  medical 
treatment  are  stated.  It 
does  not  specify  resultant 
states. 

•  TheOMSC  does  not 
specify  if  maintenance  is 
performed  on  individual 
items  or  on  groups  of 
items. 

TheOMSC  needs  a  more  exact  model 
of  maintenance.  It  must  be  possible  to 
specify  the  type  of  mai  ntenance  to  be 
performed,  the  expected  result,  the 
materials  and  effort  consumed  during 
maintenance,  etc. 

61 


Method 

Issue 
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conductRecoveryO 

TheOMSC  describes  recov¬ 
ery  as  if  it  were  an  al  l-or- 
nothing  action:  recover  all 
entities.  Presumably  an 

M  S(S  system  can  be  more 
selective,  opting  to  perform 
triage  (for  example). 

The  OMSC  needs  a  model  of  recovery 
that  descri  bes: 

•  How  to  determine  what  to  recover. 

•  The  resources  consumed  during 
recovery. 

conductEvacuationO 

•  TheOMSC  does  not  state 
how  the  location  of  a  rear 
area  is  determined. 

•  TheOMSC  does  not  define 
if  evacuation  must  be 
performed  en  masse.  M  ust 
a  whole  unit  be  evacuated, 
or  can  portions  be 
evacuated? 

•  TheOMSC  should  include  a  location 
as  a  parameter  to  the  method. 

•  TheOMSC  needs  a  model  of 
evacuation  that,  like  recovery, 
precisely  defines  what  recovery  is 
and  the  resources  it  consumes. 

The  C2  Class 

doC2() 

TheOMSC  does  not  describe 
the  nature  of  command  deci¬ 
sions  or  control  actions. 

TheOMSC  should  create  a  set  of 
classes  that  can  model  C^  actions  im¬ 
portant  to  for  M&S. 

The  Attrition  Class 

causeAttritionO 

•  TheOMSC  does  not  define 
the  actions  one  unit  can 
take  that  might  cause 
losses  to  another  unit.  If 
those  actions  include 
firing  weapons,  it  would 
seem  more  logical  to 

i  nvoke  the  weapon  fi  ri  ng 
method  di  rectly  than  to 
invoke  it  through  this 
method. 

•  TheOMSC  does  not 
specify  how  much  attrition 
is  caused  by  invoking  this 
method. 

TheOMSC  needs  a  model  that  relates 
attrition  to  the  various  actions  one 
unit  might  take  against  another. 
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The  Communications  Class 

•  getNetO 

•  setNetO 

•  TheOMSC  does  not 
specify  the  types  of  objects 
that  might  be  modeled  in 
a  network.  Presumably  it 

i  ncl  udes  components  of 
the  unit  hierarchy.  It  may 
also  include  platforms. 

•  Does  "Capable  of 
exchanging  messages" 
include  both  friends  and 
foes? 

•  Is  the  intent  of 
communications  to 

ca  pt  u  re  el  ect  ron  i  c  message 
exchange?  Or  does  it 
i  ncl  ude  other  types  of 
signals  (e.g.,  semaphores, 
written  communication,  or 
for  that  matter  verbal 
communication)? 

TheOMSC  needs  a  more  precise 
model  that  captures  how  units  com¬ 
municate  in  simulations 

Theintei  Class 

collectO 

•  TheOMSC  does  not 
specify  how  the  organic 
sensor  assets  of  a  unit  are 
defined. 

•  Detection  involves  more 
than  turning  on  a  sensor. 
The  sensor  is  typically 
directed  against  some 
feature,  other 
organization,  etc.  The 

OM  SC  does  not  defi  ne  how 
search  capabilities  may  be 
effected  other  than 
turning  them  on. 

•  TheOMSC  must  specify  how  the 
sensor  assets  of  a  unit  are  defined. 

•  The  OMSC  must  specify  how  the 
sensor  assets  of  a  unit  may  be  used. 

reportContactsO 

TheOMSC  does  not  specify 
the  nature  of  results,  nor 
how  they  might  be  used.  The 
only  other  method  associ¬ 
ated  with  a  U  nit  that  might 
use  intelligence  is  C2.doC2(). 

TheOMSC  needs  a  class  that  acts  as  a 
superclass  of  possi  ble  results  for  the 
collectO  method. 
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Method 

Issue 

Recommendations 

The  Platform  Standard  Object 

The  Platform  Class 

getTypeO 

TheOMSC  does  not  define 
what  a  type  designation  is. 
Assuming  that  Platform  is  a 
virtual  class  and  that  actual 
platform  instances  would  be 
members  of  subtypes  of 
Platform,  the  type  designa¬ 
tion  is  probably  just  an 
identifying  string  that  gives 
the  name  of  the  subtype. 

TheOMSC  needs  to  enumerate  at 
least  a  partial  list  of  valid  platform 
types. 

assessDamageO 

•  TheOMSC  does  not 
specify  the  types  of  objects 
that  might  cause  damage. 

•  TheOMSC  does  not 
specify  how  the  amount  of 
damage  i  s  determi  ned. 

•  The  description  states  that 
the  method  calculates 
damage  caused,  but  there 
is  no  method  associated 
with  a  Platform  that 
actually  causes  damage. 

•  TheOMSC  does  not 
specify  units  in  which 
damage  is  measured. 

•  TheOMSC  does  not 
specify  how  the  object  that 
caused  the  damage  is 
identified,  if  more  than 
one  object  can  cause 
damage,  or  what  an  object 
might  be  (Can  damage  to 
a  truck  come  from  a  rock? 

1  f  not,  how  does  one  model 
such  potential  damage?). 

•  This  method  assesses 
damage.  How  is  damage 
caused?  What  entities  are 
consumed  in  causing  it? 

TheOMSC  needs  a  model  of  damage. 

The  Sensor  Class 

getMaxRangeO 

TheOMSC  does  not  pre¬ 
scribe  the  units  of  range. 

TheOMSC  should  standardize  the 
units  and  precision  of  range. 
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Method 

Issue 

Recommendations 

getContactsO 

A  Platform  does  not  have  a 
location.  Without  a  location, 
how  can  the  contacts  be  de- 
termined?  (The  Unit  class  has 
a  collection  of  Platform  in¬ 
stances,  and  moreover  may 
be  hierarchically  composed 
of  Unit  instances.  Perhaps  a 
Platform's  location  is  always 
the  center  of  mass  of  its  con- 
taining  Unit,  wherethe 

Unit's  granularity  is  small 
enough  to  resolve  the  prob¬ 
lem  of  locating  contacts.) 

TheOMSC  needs  to  clarify  the  method 
by  which  contacts  are  gathered,  and 
whether  it  requires  a  location;  if  it 
does.  The  OM  SC  needs  to  clarify  how 
the  location  of  a  platform  is  deter¬ 
mined. 

The  Weapon  Class 

getMaxRangeO 

TheOMSC  does  not  pre¬ 
scribe  the  units  of  range. 

TheOMSC  needs  to  define  the  units 
and  precision  of  range. 

loadO 

The  OM SC's  description  of 
loading  "a"  munition  seems 
oriented  towards  particular 
types  of  weapons,  like  artil¬ 
lery.  Is  that  the  intent? 

The  OM  SC  needs  to  clarify  the  range 
of  weapons  to  which  this  operation  can 
be  applied. 

engageTargetO 

•  TheOMSC  does  not 
indicate  how  long  the 
weapon-firing  event  takes. 
Is  this  captured  in  a 
subtype?  It  should  be  a 
virtual  method. 

•  There  is  no  method  to 
determi  ne  whether 
weapon  firing  has  ended. 

•  Is  aiming  part  of  engaging 
a  target?  There  is  no  aim() 
method. 

TheOMSC  needs  a  model  of  weapon 
firing.  The  model  should  allow  a  sys¬ 
tem  to  determine  if  a  weapon  has  been 
fired,  where  it's  pointing,  and  things 
like  that. 

The  PlatformFrame  Class 

getSignatureO 

•  TheOMSC  lists  examples 
of,  but  does  not  describe 
the  full  range  of, 
signatures.  Nor  does  it 
provide  a  general  means 
to  encapsulate  signatures 
(e.g.,  a  virtual  class 
Signature). 

•  The  method's  description 
is  worded  as  if  a  target 
has  a  single  signature. 

Can't  a  target  have 
multiple  signatures? 

TheOMSC  should  define  a  virtual 
dass  Signature,  which  would  be  the 
value  returned  by  getSignatureO.  Sensors 
would  return  subclasses 
(Thermals ignature,  AcousticSignature,  etc). 
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7.2  General  Recommendations 

7.2.1  Recommendations  for  the  AlCDM 

The  AICDM  is  a  comprehensive  model  of  C2  systems.  Its  designers  did  not,  however, 
consider  modeling  and  simulation  system  entities  when  they  designed  it.  The  following 
subsections  list  general  changes  to  the  AICDM  that  would  improve  its  ability  to  serve  as 
a  data  model  for  M&S  systems. 

7.2. 1.1  Entity  State 

Knowing  the  current  state  of  an  entity  is  vital  in  a  simulation.  Much  of  the  work  done  by 
an  M&S  system  is  concerned  with  computing  a  future  state,  and  a  future  state  is  deter¬ 
mined  by  the  current  state.  The  AICDM  records  certain  state  attributes,  but  mainly  those 
of  interest  in  the  logistics  community.  Thus,  the  AICDM  models  a  vehicle’s  location,  but 
does  not  model  its  velocity  (either  speed  or  orientation^).  But  using  velocity  as  the  basis 
for  calculating  a  future  state  of  a  vehicle  is  one  of  the  most  elementary  operations  of 
simulation. 

We  therefore  recommend  that  the  AICDM  be  augmented  to  include  the  capability  to 
model  a  set  of  entity  states  deemed  of  interest  to  the  M&S  community.  The  following 
properties  must  be  added  to  support  current  OMSC  methods: 

•  Velocity 

•  Sensor  state  (on  or  off) 

•  Weapon  state  (loaded  vs.  unloaded,  firing  vs.  idle) 

7. 2. 1.2  Physical  Entity  Properties 

M&S  systems  need  to  know  certain  static  properties  of  the  entities  they  model.  The 
OMSC,  for  example,  makes  use  of  platform  signatures  as  part  of  intelligence  collection. 

The  AICDM  models  a  few  static  properties,  in  particular  size  and  weight.  But  again,  it 
sticks  to  properties  of  interest  to  the  logistics  community.  M&S  systems  need  thermal  and 
electronic  signatures,  among  others. 

We  recommend  that  research  be  conducted  on  modeling  entity  properties,  and  that  a  data 
model  for  these  properties  be  incorporated  into  the  AICDM. 

7. 2. 1.3  J  oint,  Foreign,  and  Commercial  Entities 

Currently,  the  AICDM  is  focused  on  meeting  the  Army  warfighter’s  data  needs  for  C4I 
systems  and  includes  extensive  representations  for  Army  forces  (military  units)  and  their 
materiel.  However,  in  training  simulations,  many  other  entities  (organizations,  vehicles, 
equipment,  facilities)  besides  those  under  U.S.  Army  Command  and  Control  may  need 
representation  in  order  to  represent  the  interactions  of  U.S.  Army  forces  with  Joint  and 
Coalition  Forces,  as  well  as  opposing  forces  and  civilian  entities.  Hence,  if  the  AICDM  is 


^  Note  too  that  the  orientation  component  of  veloeity  may  not  be  enough  information  for  a  simula- 
tion.C4I  modeling  sometimes  assumes  that  an  objeet  is  oriented  in  the  direction  it’s  moving.  An  air¬ 
craft  in  a  crosswind  violates  this  assumption. 
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to  support  these  M&S  data  representation  requirements,  it  would  benefit  from  an  expan¬ 
sion  of  its  entities  and  relations  to  eover  more  types  of  entities  outside  of  the  current  fo¬ 
cus  on  U.S.  Army  entities. 

Some  more  specific  requirements  include  entities  for  water  vehicles  and  spacecraft  to  ac¬ 
commodate  interactions  with  naval  vessels  as  well  as  possible  communications  depend¬ 
encies  on  satellites.  Supporting  just  these  requirements  would  improve  AICDM  modeling 
capabilities  for  Joint  exercises.  It  appears  as  though  the  adequate  representation  of  for¬ 
eign  forces  may  require  other  additions  as  well.  The  current  AICDM  representations  for 
MATERIEL,  for  example,  seem  to  have  dependencies  on  materiel-item  identifiers  and  na¬ 
tional  stock  numbers  which  may  not  be  available  for  the  equipment  of  many  foreign 
forces.  This  issue  requires  further  investigation. 

Modeling  of  civilian  and  commercial  entities  could  benefit  from  a  richer  hierarchy  of  or¬ 
ganization  types.  Currently,  the  only  subtypes  of  the  AICDM  ORGANIZATION  entity  are  the 
UNIFORMED-SERVICE-ORGANIZATIONs  of  CONVOY,  MILITARY-UNIT,  and  ORGANIZATION-POST. 
Civilian  organizations  may  benefit  from  additional  subtypes  to  capture  their  relevant 
characteristics,  especially  the  so-called  Non-Governmental-Organizations  (NGO’s)  which 
interact  with  the  military  in  Operations  Other  Than  War  (OOTW)  such  as  disaster  relief. 
Further  investigations  are  required  to  assess  the  extent  to  which  additional  data  represen¬ 
tations  are  needed  for  foreign  and  civilian  entities  to  support  M&S  requirements. 

Existing  parts  of  the  DDA  which  are  outside  of  the  current  scope  of  the  AICDM  can  sat¬ 
isfy  most  of  these  requirements.  The  DDA  SHIP  entity  and  its  rich  web  of  associated  enti¬ 
ties,  for  example,  should  meet  Army  M&S  requirements  for  water  vehicle  representa¬ 
tions.  There  is  also  a  SATELLITE  entity  in  the  DDA  which  may  meet  M&S  requirements 
for  representing  spacecraft. 

There  are  a  variety  of  alternative  approaches  to  meeting  these  new  data  representation 
requirements.  The  AICDM  could  incorporate  appropriate  existing  entities  from  the  DDA 
and  add  new  ones  as  required.  Separate  “annexes”  could  be  created  for  the  AICDM  for 
those  data  requirements  that  do  not  meet  C4I  core  data  needs,  thereby  keeping  the 
AICDM  itself  as  a  relatively  streamlined  “core”  for  C4I  data  modeling.  Alternatively,  ap¬ 
plications  requiring  these  extended  capabilities  might  be  referred  to  the  general  DDA,  or 
parts  thereof,  as  the  source  for  non-core  data  representations.  We  do  not  make  any  general 
recommendations  on  a  preferred  course  of  action  here,  as  broader  policy  issues  are  rele¬ 
vant.  But,  we  do  recommend  that  a  policy  be  developed  for  handling  representations  of 
such  data,  when  it  falls  outside  of  the  “core”  scope  of  Army  C4I  systems. 

7.2. 1.4  Linkages  Between  Existing  Entities 

While  the  AICDM  generally  benefits  from  a  very  rich  set  of  associations  amongst  its  enti¬ 
ties,  there  is  at  least  one  case  in  which  important  relationships  do  not  exits.  The  example 
we’ve  identified  of  this  is  for  the  AIRCRAFT  entity,  which  would  ordinarily  be  considered  a 
type  of  materiel,  along  with  other  vehicles,  such  as  tanks.  However,  the  AIRCRAFT  entity 
does  not  have  any  connection  to  the  MATERIEL  entity  in  the  examined  AICDM  model.  As 
a  result,  it  cannot  use  MATERIEL  entity  associations  to  identify  its  associated  location, 
crew,  or  materiel  as  supplies  or  cargo.  Since  the  AIRCRAFT  entity  is  found  in  an  area  of  the 
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AICDM  that  is  still  “to  be  worked,”  this  defieieney  may  will  be  reetified  by  the  time 
these  entities  are  ready  for  submission  to  DISA  in  a  proposal  paekage.  Also,  the  DDA 
eontains  extensive  additional  AIRCRAFT-related  entities  whieh  eould  be  ineorporated  in  the 
AICDM  to  meet  these  requirements. 

7.2. 1.5  Non-Administrative Organizations 

The  AICDM  ORGANIZATION  entity  models  “an  administrative  strueture  with  a  mission.”  A 
striet  interpretation  of  this  phrase  would  preelude  the  AICDM  from  modeling  operational 
struetures — e.g.,  ad  hoe  organizations,  sueh  as  a  group  of  wounded  warfighters  being 
evaeuated.  An  operational  strueture  entity  would  be  useful  in  modeling  the  effeets  of  The 
OMSC  methods  that  operate  on  quantities  of  items. 

The  AICDM  should  elarify  its  intention  regarding  the  possible  use  of  ORGANIZATION  to 
model  operational  as  well  as  administrative  struetures.  If  ORGANIZATION  is  to  be  used 
solely  for  administrative  struetures,  the  AICDM  should  be  enhaneed  to  inelude  entities 
and  relationships  that  ean  model  operational  struetures. 

7.2.2  Recommendations  for  the  OMSC 

As  a  high-level  arehiteetural  model  of  M&S  systems,  the  OMSC  has  goals  not  eonneeted 
to  data  model  alignment.  Nevertheless,  there  are  several  pervasive  but  straightforward 
ehanges  that  eould  be  made  to  the  OMSC  in  order  to  improve  alignment.  Appendix  B 
motivates  the  need  for  these  ehanges.  The  following  subseetions  deseribe  them. 

7. 2. 2.1  ResolveAmbiguities 

The  OMSC’s  deliberately  vague  deseriptions  of  its  elasses  and  methods  prevents  real  un¬ 
derstanding  of  the  degree  to  whieh  the  OMSC  and  the  AICDM  align.  The  OMSC  should 
address  this  situation  by  taking  the  following  notions: 

•  Provide  parameter  schemata  for  all  methods.  This  would  provide  useful  detail 
on  all  entities  assooiated  with  an  notion.  Movement  is  an  example  that  has  been 
mentioned  throughout  this  report.  Another  good  example  is  attrition.  If  the 
OMSC  defined  the  parameters  of  the  causeAttrltlonO  method,  it  would  be  possible 
to  determine  whether  the  AICDM  models  the  entities  that  oause  attrition,  the 
amount  of  attrition  they  ean  oause,  the  time  at  whieh  they  oause  it,  eto. 

It  has  been  pointed  out  that  not  speoifying  a  method’s  parameter  soheme  allows  more 
forms  of  a  method  to  fit  into  the  general  arohiteoture.  In  that  ease,  the  arohiteoture  be- 
oomes  more  notional  than  oonorete.  The  AICDM  is  a  oonorete  data  model,  and  align¬ 
ing  it  to  a  notional  M&S  model  is  diffioult,  as  this  report  has  shown.  In  any  ease, 
overloading  ean  be  used  to  aooommodate  multiple  parameter  sohemata. 

•  Specify  return  values  for  all  methods.  This  aotion  is  analogous  to  the  previous 
one.  Speeifying  a  method’s  return  value  better  deseribes  the  types  of  entities 
with  whieh  a  method  interaets. 

•  Include  class  constructors.  Construetors  help  establish  what  eonstitutes  a  valid 
instanee  of  a  elass.  (For  example,  must  a  unit  have  an  ID?)  If  the  OMSC  pro¬ 
vided  eonstruetors,  we  eould  map  the  aetion  of  ereating  an  objeet  instanee  to  a 
set  of  AICDM  entities,  attributes,  and  relationships.  Currently  we  ean  define  the 
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necessity  of  attributes  having  values,  and  of  relationships  existing  between  enti¬ 
ties,  based  on  invoking  a  method,  but  we  cannot  aver  that  a  particular  set  of  re¬ 
lationships  must  always  exist,  or  that  a  specific  set  of  attributes  have  interre¬ 
lated  values. 

•  Include  set  as  well  as  get  methods.  This  action  is  analogous  to  including  class 
constructors.  Set  methods  often  make  apparent  constraints  between  instance 
properties.  They  also  show  which  properties  are  immutable,  and  which  cannot 
be  directly  defined  (e.g.,  a  setLocationO  method  is  unlikely — location  must  al¬ 
ways  be  changed  using  the  moved  method).  These  extra  semantics  facilitate 
alignment. 

UML  provides  the  opportunity  to  capture  this  and  much  more  information. 

The  OMSC  should  also  consider  using  an  established  documentation  paradigm,  such  as 
that  used  by  Sun  Microsystems  to  specify  Java  classes,  to  ensure  that  each  standard  ob¬ 
ject  is  described  as  fully  as  available  information  permits.  Java  documentation  succinctly 
captures  the  interface  of  a  class.  It  is  not  sufficient — it  does  not  fully  define  a  class’  se¬ 
mantics — but  it  presents  considerably  more  information  than  the  OMSC. 

1. 2.2.2  Base  Class  Designs  on  Objects,  Not  Algorithm  Encapsulation 

The  OMSC’s  Unit  and  Platform  standard  objects  consist  of  a  focal  class  and  an  aggregation 
of  other  classes.  Almost  all  of  these  aggregated  classes  are  designed  to  encapsulate  algo¬ 
rithms  rather  than  to  model  objects. 

For  example,  the  Unit  standard  object’s  Attrition  class  has  a  method  that  causes  attrition.  It  is 
difficult  to  conceive  of  attrition  as  an  object.  There  is  no  physical  attrition  entity.  Attrition 
is  a  concept  to  describe  loss  within  a  unit.  It  is  possible  that  a  simulation  system  might 
implement  a  message  passed  between  units  that  describes  attrition.  But  describing  such  a 
message  seems  out  of  place  in  the  OMSC’s  class  model.  It  belongs  in  a  process  model. 

The  AICDM  models  entities.  Because  attrition  is  not  an  entity,  it  does  not  exactly  align  to 
anything  in  the  AICDM.  This  report  has  speculated  on  the  characteristics  of  attrition  and 
attempted  to  find  AICDM  entities  that  can  suffer  attrition,  with  attributes  describing  how. 
The  discussion  of  determineAttritionO  and  causeAttritionO  is  the  weaker  for  it.  The  OMSC’s 
class  model  should  instead  concentrate  on  identifying  and  modeling  objects. 

7.3  Recommendation  for  Future C4I-M&S  Alignment 
Studies 

Finally,  we  offer  a  recommendation  on  addressing  the  broader  issue  of  alignment  of  C4I 
and  M&S  data  models.  The  purpose  of  this  recommendation  is  to  promote  studies  that 
optimize  the  benefits  of  alignment  to  both  the  C4I  and  the  M&S  communities. 

The  recommendation  is  to  avoid  a  mismatch  of  models  such  as  occurred  between  the 
AICDM  and  the  OMSC.  The  alignment  analysis  presented  here  was  severely  limited  by 
the  disparity  between  the  modeling  levels  of  the  OMSC  and  the  AICDM.  This  report  pro- 


See  http://iava.sun.eom/i2se/l.3/docs/api/index.html  for  examples  of  the  Java  documentation  format. 
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vides  a  good  framework  for  beginning  aetual  alignment  of  an  OMSC-based  system  to  an 
AICDM-based  system.  But  the  results  are  based  on  numerous  hypotheses  identified  in 
Appendix  A,  and  any  aetual  alignment  is  likely  to  require  work  in  areas  not  foreseen  in 
this  report.  More  plainly,  some  of  the  methods’  alignment  ratings  will  prove  too  high  be- 
eause  of  false  assumptions. 

In  the  future,  the  AICDM  should  be  aligned  to  an  M&S  model  that  provides  mueh  more 
detail  on  elasses,  methods,  and  semanties. 
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Abbreviations  and  Acronyms 


ABCS 

Army  Battle  Command  Sys¬ 
tems 

AFATDS 

Advaneed  Field  Artillery  Tac- 
tieal  Data  System 

AICDM 

Army  Integrated  Core  Data 
Model 

AMSAA 

Army  Materiel  Systems 
Analysis  Aetivity 

AMSO 

Army  Model  and  Simulation 
Office 

C2 

Command  and  Control 

C2CDM 

C2  Core  Data  Model 

C3I 

Command,  Control,  Commu¬ 
nications  &  Intelligence 

C4 

Command,  Control,  Commu¬ 
nications,  and  Computers 

C4I 

Command,  Control,  Commu¬ 
nications,  Computers,  &  Intel¬ 
ligence 

COE 

Common  Operating  Environ¬ 
ment 

DB 

Database 

DBMS 

Database  Management  Sys¬ 
tem 

DDA 

DoD  Data  Architecture 

DDDS 

Defense  Data  Dictionary  Sys¬ 
tem 

DDM 

DoD  Data  Model 

DII 

Defense  Information  Infras¬ 
tructure 

DISA 

Defense  Information  Systems 
Agency 

DoD 

Department  of  Defense 

ER 

Entity-Relationship 

FOM 

Federation  Object  Model 

GH4 

Generic  Hub  data  model,  ver¬ 
sion  4 

HLA 

High  Level  Architecture 

IDA 

Institute  for  Defense  Analyses 

IDEFIX 

Integrated  Definition  for  In¬ 
formation  Modeling 

IEEE 

Institute  for  Electrical  and 
Electronics  Engineers 

JCDB 

Joint  Common  Database 

JTA 

Joint  Technical  Architecture 

JTA-A 

Joint  Technical  Architecture — 
Army 

M&S 

Modeling  and  Simulation 

MIDB 

Modernized  Intelligence  Da¬ 
tabase 

MRCI 

Modular  Reconfigurable  C4I 
Interface 

NGO 

Non-Governmental  Organiza¬ 
tion 

NIST 

National  Institute  of  Standards 
and  Technology 

ODISC4 

Office  of  the  Director  for  In¬ 
formation  Services  for  C4 

Acros-l 


OMSC  Object  Management  Stan¬ 

dards  Category 

00  Object  Oriented 

OOTW  Operations  Other  Than  War 

SQL  Structured  Query  Language 

URL  Uniform  Resource  Locator 

UML  Unified  Modeling  Language 

WARSIM  Warfighters  Simulation 
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Appendix  A. 
Alignment  Analysis 


This  appendix  presents  the  alignment  analysis.  It  identifies  how — or  if — AICDM  entities 
and  attributes  relate  to  OMSC  standard  objeets,  elasses,  and  methods.  It  provides  a  refer- 
enee  guide  to  whieh  eoneepts,  entities,  and  properties  align  between  the  two  models.  It 
does  not  define  degree  of  alignment,  but  instead  gives  the  preparatory  work  needed  for 
ealeulating  degree. 

Appendix  A  is  organized  hierarehieally,  as  shown  in  Figure  A-1.  Nodes  in  the  tree  repre¬ 
sent  seetions.  Top-level  seetions  eorrespond  to  Coneeptual  level  alignment.  Subseetions 
eorrespond  to  Entity  level  alignment.  Sub-subseetions  eorrespond  to  State  level  align¬ 
ment. 


Conceptual  level 


Entity  level 


State  level 


Alignment  Analysis 


Unit  standard  objeet  Platform  standard  objeet 


Unit  elass  UnitGeometry  elass  ... 


getUoeationO  method  getID()  method 


Figure  A-1.  Organization  of  Alignment  Analysis 

The  analysis  is  organized  around  OMSC  modeling  elements,  refleeting  the  foeus  of  our 
alignment  on  mapping  from  OMSC  to  AICDM  elements  (see  Seetion  5).  Thus  Coneep¬ 
tual  level  analysis  begins  by  ehoosing  an  OMSC  standard  objeet  and  identifying  or  defin¬ 
ing  an  AICDM  view  that  aligns  with  it.  Entity  level  analysis  aligns  eaeh  OMSC  elass 
within  a  standard  objeet  with  AICDM  entities  from  the  eorresponding  AICDM  view. 
State  level  analysis  eonsists  of  examining  a  elass’  methods  and,  for  eaeh  method, 
identifying  eorresponding  AICDM  attributes  within  entities  that  align  to  the  elass. 

There  is  no  Value  level  alignment.  The  OMSC  does  not  provide  enough  details  to  support 
it.  The  definition  of  alignment  gives  attribute  domains  no  role  outside  of  Value  level 
alignment.  But  sometimes  an  examination  of  an  AICDM  attribute’s  domain  helps  support 
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State  level  analysis.  There  is  no  point  in  disearding  useful  information,  so  it’s  eaptured. 
Paragraphs  eontaining  information  that  properly  belongs  at  the  value  level  are  speeially 
marked: 


A  paragraph  eontaining  information  derived  from  Value  level  analysis  has  a 
tag  at  the  top  of  its  right  margin. 


Value 


The  analysis  results  for  the  Coneeptual  level  appears  in  tables.  The  following  is  a  brief 
explanation  of  these  tables. 


For  eaeh  OMSC  standard  objeet,  there  is  one  table  eontaining  Coneeptual  level  analysis. 
This  table  has  three  eolumns: 


•  OMSC  Class:  This  eolumn  lists  all  the  elasses  in  a  given  standard  objeet.  Eaeh  row 
lists  one  of  the  elasses  from  the  OMSC  standard  objeet. 

As  Seetion  A.2  explains,  there  are  four  eategories  of  platforms.  The  Coneeptual  level 
analysis  table  for  the  Platform  standard  objeet  (page  A-49)  aeeordingly  breaks  elasses 
into  four  rows,  one  for  eaeh  platform  eategory. 

•  Related AICDM Entity:  This  eolumn  lists  the  major  AICDM  entities  in  the  view  that 
align  with  the  OMSC  elasses  in  the  first  eolumn  (other  entities  enter  the  view  through 
relationships;  see  the  last  bullet).  Eaeh  row  in  the  eolumn  lists  one  or  more  entities 
that  have  some  degree  of  eoneeptual  alignment  with  the  OMSC  elass  in  the  first  eol¬ 
umn  of  that  row. 


If  an  AICDM  entity  is  a  subtype  in  a  hierarehy,  its  supertypes  are  only  listed  in  this 
eolumn  the  first  time  the  entity  appears.  Supertypes  ean  be  identified  via  the  relation¬ 
ships  traeed  to  the  foeal  entity  in  the  third  eolumn. 

•  Relation  to  Focal  Entity:  Coneeptual  level  alignment  speeifies  not  only  AICDM  enti¬ 
ties  but  how  those  entities  relate  to  the  foeal  entity  of  the  view.  This  eolumn  defines 
that  relationship  for  the  entities  in  the  first  eolumn.  The  definition  is  in  terms  of  fig¬ 
ures,  expressed  in  the  IDEE IX  notation.  The  reader  ean  refer  to  the  referenee  figure 
to  determine  the  exaet  set  of  entities  and  relationships. 

Entities  in  the  first  eolumn  aren’t  always  assoeiated  with  the  foeal  entity  by  a  single 
relationship.  For  one  thing,  if  two  entities  have  a  many-to-many  relationship,  the 
AICDM  expresses  that  relationship  using  an  intermediate  entity  (e.g.,  MATERIEL- 
LOCATION  relates  MATERIEL  to  LOCATION).  For  another,  an  entity  in  the  first  eolumn  is 
often  a  subtype  of  some  other  entity,  and  the  latter  entity  is  the  one  that  partieipates  in 
relationships  (e.g.,  MILITARY-UNIT  is  a  subtype  of  ORGANIZATION;  ORGANIZATION,  not 
MILITARY-UNIT,  is  related  to  PERSON,  MATERIEL,  ete.).  The  AICDM  view  that  is  aligned 
with  a  standard  objeet  ineludes  the  intermediate  entities  and  supertypes,  as  listed  in 
the  third  eolumn.  The  view  therefore  eonsists  of  all  entities  and  relationships  in  the 
seeond  eolumn  of  the  table,  plus  all  entities  and  relationships  implied  by  the  third 
eolumn  of  the  table. 
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The  analysis  results  for  the  Entity  level  appears  in  a  table  if  the  OMSC  elass  has  methods. 
Otherwise,  it  is  stated  as  free  text.  For  eaeh  OMSC  elass  with  methods,  there  is  one  En¬ 
tity  level  analysis  table.  This  table  has  the  following  three  eolumns: 

•  AICDM  Entity:  This  eolumn  eaptures  both  those  entities  identified  as  aligned  with  an 
OMSC  elass  at  the  Coneeptual  level  and  any  additional  AICDM  entities  that  eover  the 
speeifie  representational  needs  of  the  methods  of  that  OMSC  elass.  The  set  of  entity 
names  in  eaeh  row  aligns  to  the  OMSC  elass  in  question. 

•  Suggested  By:  This  eolumn  eontains  the  names  of  methods  of  the  table’s  OMSC 
elass.  Eaeh  row  has  one  or  more  methods  of  the  elass  being  analyzed.  Eaeh  method’s 
name  motivates  the  need  for  the  entity  (or  entities)  in  the  first  eolumn. 

•  Relation  to  Focal  Entity:  Entity  level  alignment  speeifies  not  only  AICDM  entities 
but  how  those  entities  relate  to  the  foeal  entity  of  the  view.  This  eolumn  defines  that 
relationship  for  the  entities  in  the  first  eolumn. 

The  intermediate  entities  listed  in  this  eolumn  aren’t  in  the  set  of  entities  that  align  to 
the  OMSC  elass.  A  standard  objeet  speeifies  a  relationship  between  its  foeal  elass  and 
other  elasses  (either  aggregation  or  inheritanee).  This  eolumn  demonstrates  that  the 
AICDM  ean  model  that  relationship. 

The  analysis  results  for  the  State  level  are  stated  as  free  text.  Most  OMSC  methods  have 
ambiguities.  All  ambiguities  that  hinder  State  level  alignment  analysis  are  noted.  The 
analysis  then  presents,  using  the  standard  phrasing  from  Table  7  (reprodueed  below  as 
Table  A-1),  the  estimated  degree  of  alignment  for  the  method.  (The  phrase  is  shown  in 
boldfaee  type  for  easy  identifieation.)  This  is  followed  by  detailed  diseussion  justifying 
the  estimate. 


Table  A-1.  Possible  Degrees  of  Alignment 


Value 

Standard  Phrase 

Meaning 

0% 

No  alignment 

This  value  is  assigned  in  either  of  the  foil  owing  circum¬ 
stances: 

•  There  is  no  overlap  between  the  models.  One  model 
contains  an  instance  of  an  element  that  has  no  analog  in 
the  other. 

•  Lack  of  information  in  the  OMSC  completely  prevents 
alignment  analysis. 

25% 

Low  degree  of  align¬ 
ment 

There  is  some  overlap,  but  it  seems  coincidental.  Overlap 
might  have  been  achieved  by  using  AICDM  attributes  in 
ways  that  its  designers  did  not  originally  intend. 

50% 

Medium  degree  of 
alignment 

Thereis  a  moderate  amount  of  overlap,  but  still  a  signifi¬ 
cant  disconnect  between  the  models. 

75% 

High  degree  of  align¬ 
ment 

Perfect  alignment  can  probably  be  achieved  by  small 
changes  to  one  model  or  the  other. 

100% 

Perfect  alignment 

There  is  an  exact,  unambiguous  mapping  between  the 
models. 
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The  tables  that  present  Coneeptual  and  Entity  level  alignment  should  be  regarded  as 
summaries.  They  do  not  attempt  to  provide  all  the  details  on  the  AICDM  and  the  OMSC, 
or  on  how  the  models  are  used.  Notes  are  often  used  to  explieate  material  in  the  tables, 
and  figures  are  provided  to  show  AICDM  entities,  attributes,  and  relationships  (eonsistent 
with  the  definition  of  alignment,  figures  in  the  seetions  on  Coneeptual  level  alignment 
usually  show  entities  without  attributes,  and  figures  in  the  seetions  on  Entity  and  State 
level  alignment  usually  show  entities  with  attributes).  Also,  the  lowest  level  subseetions 
have  some  free  text  deseriptions  of  subtle  points.  In  any  ease,  it  is  probably  wise  to  read 
this  appendix  with  doeumentation  for  the  AICDM  and  the  OMSC  standard  objeets  near  at 
hand. 

A.l  Unit  Standard  Object  (Conceptual  Level) 

The  OMSC  defines  Unit  as  follows  [HB  1998 A]: 

A  Unit  encompasses  military  organizations  that  represent  collections  of  entities 
(e.g.,  people,  vehicles,  weapon  systems,  etc.).  Examples  of  this  definition  include 
organizations  (i.e.,  companies,  battalions,  brigades,  divisions,  etc.)  as  well  as 
functional  groups  (e.g.,  Tactical  Operations  Centers  and  Fire  Control  Centers). 

The  class  Unit  is  the  focal  class  of  the  Unit  standard  object. 

The  AICDM  ORGANIZATION  view  contains  the  principal  entities  that  model  military  or¬ 
ganizations.  The  MILITARY-UNIT  entity  in  the  ORGANIZATION  view  aligns  most  closely  with 
the  OMSC’s  Unit  class  and  is  used  as  the  focal  entity  of  our  corresponding  AICDM 
view.^  Table  A-2  shows  the  entities  of  interest,  and  how  they  relate  to  a  MILITARY-UNIT. 


*  Arguably,  the  FACILITY  entity  aligns  most  closely  with  a  fire  control  center.  If  it  is  appropriate  to  model 
a  fire  control  center  as  a  FACILITY,  that  FACILITY  can  still  be  related  to  an  ORGANIZATION  through  the 
ORGANIZATION-FACILITY  entity. 
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Table  A-2.AIC DM  Entities  that  Align  with  Classes  of  the  Unit  Standard  Object  at 

the  Conceptual  Level 


OMSC  Class 

Related 

AICDM  Entity 

Relation  to  MILITARY-UNIT 

Unit 

MILITARY-UNIT 

Identical  (the  same  entity) 

UnitGeometry 

SURFACE  and  its  sub- 
types 

A  MILITARY-UNIT  is  a  subtype  of  a  UNIFORMED- 
SERVICE-ORGANIZATION,  which  is  a  subtype  of 
ORGANIZATION.^  An  ORGANIZATION  has  an  associ¬ 
ated  CONTROL-FEATURE  (a  subtype  of  FEATURE) 
that  is  used  to  describe  the  organization's 
shape.  The  AICDM  models  the  shape  through 
an  association  between  a  CONTROL-FEATURE  and 
a  LOCATION;  oneof  the  subtypes  of  LOCATION  is 
SURFACE,  whose  subtypes  can  describe  arbitrary 
two-dimensional  shapes.  SeeFigureA-2  and 
FigureA-10. 

A  FEATURE  is  used  to  describe  the  location  of  a 
largeORGANIZATION.  A  small  ORGANIZATION 
(down  to  an  individual)  may  be  associated  more 
directly  with  a  LOCATION  via  an  ORGANIZATION- 
LOCATION.  SeeFigureA-2. 

Intel 

SENS0R-TYPE3 

A  MILITARY-UNIT  has  associated  MATERIEL-ITEM  en¬ 
tities;  the  association  records  the  number  of 
such  entities.  SENSOR-TYPE  is  a  subtype  of 
MATERIEL-ITEM.  See  Figure  A-4. 

Communications 

TELECOMMUNICATIONS- 
NETWORK-ELEMENT  and 
its  subtypes 

A  MILITARY-UNIT  has  associated  MATERIEL-ITEM  en¬ 
tities.  A  subtype  of  MATERIEL-ITEM  is 
TELECOMMUNICATIONS-NETWORK-DEVICE,  which 
has  a  many  to  many  relationship  with 
TELECOMMUNICATIONS-NETWORK-ELEMENT.  Sub- 
types  of  TELECOM  MUNICATIONS-NETWORK-ELEMENT 
describe  various  kinds  of  telecommunications 
devices.  See  Figure  A-6. 

SystemGroup 

MATERIEL-ITEM  and  its 
subtypes,  e.g.  SENSOR- 
TYPE 

A  system  is  a  type  of  materiel A  MILITARY-UNIT 
has  associated  MATERIEL-ITEM  entities,  which  de¬ 
scribe  materiel  types.  The  association  (via  a 
HOLDING  entity)  records  the  number  of  such  enti¬ 
ties.  SENSOR-TYPE  is  a  subtype  of  MATERIEL-ITEM. 
See  Figure  A-4. 

^  For  brevity,  the  subtype  relationship  between  MILITARY-UNIT  and  ORGANIZATION  will  be  omitted  in  the 
future. 

^  There  is  a  proposal  to  add  an  entity  named  INFORMATION-REFERENCE  to  the  AICDM.  INFORMATION- 
REFERENCE  is  a  pointer  to  any  kind  of  relevant  data.  This  entity  might  be  relevant  to  intelligence. 

The  OMSC  methods  for  a  SystemGroup  return  only  properties  related  to  system  type  and  number.  Fu¬ 
ture  extensions  to  OMSC  may  require  including  AICDM  entities  that  model  materiel,  not  just  materiel 
type. 
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OMSC  Class 

Related 

AlCDM  Entity 

Relation  to  MILITARY-UNIT 

Platform 
(ground,  wa¬ 
ter,  and  space 
platforms) 

MATERIEL 

A  platform  can  be  a  type  of  materiel. 

Since  a  Platform  is  an  instance,  a  system  may 
choose  to  associate  a  MATERIEL  platform  with  a 
MILITARY-UNIT  through  MATERIEL-ORGANIZATION. 
SeeFigureA-7. 

Platform  (person 
platforms) 

PERSON 

A  platform  can  also  be  a  person.  A  MILITARY-UNIT 
has  associations  with  a  PERSON.  See  Figure  A-4. 

Platform  (air 
platforms) 

AIRCRAFT 

None;  currently,  air  platforms  are  represented 
separately  from  other  types  of  materiel  in  the 
AlCDM.  However,  there  are  no  associations  be¬ 
tween  a  MILITARY-UNIT  and  INDIVIDUAL  AIRCRAFT. 

Platform  (static 
platforms) 

FACILITY 

A  platform  can  also  be  a  facility  (such  as  a  mis- 
silesilo).  A  MILITARY-UNIT  has  associations  with 
FACILITY  and  FACILITY-TYPE.  See  Figure  A-5. 

Platforminfo 
(ground,  wa¬ 
ter,  and  space 
platforms) 

•  EQUIPMENT-TYPE 

•  VEHICLE-TYPE 

Platforminfo  gives  signature  information  about  a 
platform.  If  the  platform  is  materiel,  a  MILITARY- 
UNIT  has  associated  MATERIEL  and  MATERIEL-ITEM 
entities  (see  Figure  A-4).  The  signature  infor¬ 
mation  for  materiel  that  the  AlCDM  can  model 
includes  dimensions,  cross-sectional  properties, 
and  weight.  TheEQUIPMENT-TYPE  andVEHICLE- 
TYPE  entities  model  dimensions  and  weight. 

1  f  a  system  models  types  of  platforms.  Figure 

A-4  shows  how  the  EQUIPMENT-TYPE  and  VEHICLE- 
TYPE  entities  relate  to  a  MILITARY-UNIT. 

If  the  system  models  individual  platforms, 
FigureA-7  shows  how  MATERIEL  is  associated 
with  a  MILITARY-UNIT,  and  how  MATERIEL  is  asso¬ 
ciated  with  MATERIEL-ITEM  subtypes  (for  signa¬ 
tures  that  apply  to  a  class  of  equipment). 

Platforminfo  (per¬ 
son  platforms) 

PERSON 

Platforminfo  gives  signature  information  about  a 
platform.  If  a  platform  is  a  person,  a  MILITARY- 
UNIT  has  associated  PERSON  entities  (see  Figure 
A-4)  that  can  model  certain  physical  character¬ 
istics  of  a  person. 

Platforminfo  (air 
platforms) 

AIRCRAFT-TYPE 

While  individual  AIRCRAFT  are  not  associated 
with  a  MILITARY-UNIT unit  in  theAlCDM,  the 
MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE 
can  associate  an  AIRCRAFT  TYPE  with  an 
ORGANIZATION. 

Platforminfo 
(static  plat¬ 
forms) 

None. 

TheAlCDM  does  not  contain  relevant  informa¬ 
tion  for  facilities. 
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OMSC  Class 

Related 

AlCDM  Entity 

Relation  to  MILITARY-UNIT 

Attrition 

•  ORGANIZATION-TYPE- 
ORGANIZATION-HOLDING- 
ESTIMATE 

•  PERSON-TYPE- 
ORGANIZATION-HOLDING- 
ESTIMATE 

•  MATERIEL-ITEM- 
ORGANIZATION-HOLDING- 
ESTIMATE 

•  PERSON 

•  MATERIEL 

A  MILITARY-UNIT  has  asscxiiations  with  materiel 
and  persons,  and  with  types  of  materiel  and 
persons.  1  n  the  former  case,  the  number  of  rela¬ 
tionships  record  the  number  of  associated  enti¬ 
ties  (see  Figure  A-4  and  Figure  A-7).  1  n  the  lat¬ 
ter  case,  the  associations  record  the  number  of 
associated  entities  (see  Figure  A-4). 

Logistics 

•  ORGANIZATION-TYPE- 
ORGANIZATION-HOLDING- 
ESTIMATE 

•  PERSON-TYPE- 
ORGANIZATION-HOLDING- 
ESTIMATE 

•  MATERIEL-ITEM- 
ORGANIZATION-HOLDING- 
ESTIMATE 

A  MILITARY-UNIT  has  associations  with  materiel 
and  persons,  and  with  types  of  materiel  and 
persons.  1  n  the  former  case,  the  number  of  rela¬ 
tionships  record  the  number  of  associated  enti¬ 
ties  (see  Figure  A-4  and  Figure  A-7).  1  n  the  lat¬ 
ter  case,  the  associations  record  the  number  of 
associated  entities  (see  Figure  A-4). 

Maintenance 

•  PERSON 

•  PERSON-OPERATIONAL- 
STATUS 

•  PERSON-CAPABILITY- 
ESTIMATE 

•  MATERIEL 

•  MATERIEL-OPERATIONAL- 
STATUS 

•  MATERIEL-CAPABILITY- 
ESTIMATE 

A  military-unit  has  associations  with  PERSON 
and  MATERIEL  entities.  These  entities  in  turn 
have  associations  with  operational  status  enti¬ 
ties.  See  Figure  A-4  and  Figure  A-7. 

The  specification  of  the  actual  functionality, 
such  as  mai  ntenance  and  supply  may  be  speci¬ 
fied  in  other  portions  of  the  DoD  Data  Architec¬ 
ture,  which  at  present  do  not  form  part  of  the 
AlCDM.  But  in  thefirst  instance  it  should  be 
possi  ble  to  assign  these  types  of  high  level  ca- 
pabilities  to  any  given  military  unit  in  charge  of 
perform!  ng  these  tasks. 

Suppiy 

•  PERSON-TYPE- 
ORGANIZATION-HOLDING- 
ESTIMATE 

•  MATERIEL-ITEM- 
ORGANIZATION-HOLDING- 
ESTIMATE 

•  PERSON 

•  MATERIEL 

•  ORGANIZATION-TYPE- 
CAPABILITY-NORM 

•  ORGANIZATION- 
CAPABILITY-ESTIMATE 

If  a  system  models  quantities,  a  MILITARY-UNIT's 
associations  with  the  entities  that  desaibe 
types  of  persons  and  materiel  include  the  quan¬ 
tities  of  each  type.  See  Figure  A-4. 

If  a  system  models  individual  entities,  a 
MILITARY-UNIT  has  associations  with  individual 
entities.  The  number  of  extant  relationships 
determi  ne  the  unit's  supply  characteristics.  See 
Figure  A-4. 

A  MILITARY-UNIT  has  associated  ORGANIZATION- 
CAPABILITY-ESTIMATE  entities  that  can  model 
maximum  supply  capabilities.  The 
ORGANIZATION-TYPE-CAPABILITY-NORM  entity  can 
model  certain  capabilities  for  classes  of  military 
units.  SeeFigureA-3. 
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OMSC  Class 

Related 

AlCDM  Entity 

Relation  to  MILITARY-UNIT 

C2 

•  ACTION,  including 
subtypes 

•  PLAN 

•  MISSION 

•  TASK 

A  Military-Unit  has  associations  with  action,  plan, 
mission,  and  task  entities.  See  Figure  A-8. 

The  degree  of  Coneeptual  level  alignment  of  the  Unit  standard  objeet  is  the  average  of 
the  degrees  of  alignment  of  its  entities  (56%). 


Figure  A-2.AIC DM  Organizations  and  Locations 
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is  the  subject  of 


ORGANIZATION 


ORGANIZATION-CAPABILITY-ESTIMATE 


is  based  on 


^  ^  ^  is  used  in 

ORGANIZATION-TYPE-ORGANIZATION  I 


UNIFORMED-SERVICE-ORGANIZATION 


the  basis  for 


CAPABILITY 


ORGANIZATION-TYPE 


performs  to 


is  used  in 


MILITARY-UNIT 


1 


ORGANIZATION-TYPE-CAPABILITY-NORM 


Figure  A-3.AICDM  Capabilities 


ORGANIZATION-TYPE-ORGANIZATION  ^ 


is  the  basis  for 


ORGANIZATION-TYPE 

^ay  be  included  in 

is  based  on  |  ORGANIZATION-TYPE-ORGANIZATION-HOLDING-ESTIMATE 
provides  ^ 


ORGANIZATION 


is  referenced  by 


UNIFORMED-SERVICE-ORGANIZATION 


MATERIEL-ITEM 

- 1 - 

is  inventoried  by 


MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATES 


may  be  included  in 


r 


MILITARY-UNIT 


identifies  ^  EQUIPMENT-TYPE 


may  be  a  PERSON-ORGANIZATION 


provides 


SENSOR-TYPE 


i 


is  associated  with 


VEHICLE-TYPE 


PERSON 


PERSON-TYPE-ORGANIZATION-HOLDING-ESTIMATE 

|may  be  included  in 

may  be  the  type  for 


PERSON-TYPE 


LOCATION 


locates 


-•  PERSON-LOCATION 


occupies 


is  described  by 


PERSON-OPERATIONAL-STATUS 


Figure  A-4^  AlC DM  Materiel  and  Personnel  Quantities 
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Figure  A-5.  AlC DM  Organization  and  Facilities 


Figure  A-6.  AlCDM  Telecommunications 
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participates  in 


Figure  A-7.AICDM  Materiel 
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Figure  A-8.AICDM  Actions,  Missions,  Plans,  and  Tasks 

A.1.1.  Unit  Class  (Entity  Level) 

The  Unit  class  aligns  with  the  AICDM  entity  MILITARY-UNIT,  the  focal  entity  of  the  Military 
Unit  view.  The  names  of  Unit’s  methods  show  the  need  for  other  AICDM  entities  and  rela¬ 
tionships  if  an  instance  of  Unit  is  to  be  fully  modeled  in  the  AICDM,  because  the  attributes 
of  MILITARY-UNIT  do  not  appear  to  encompass  the  range  of  concepts  those  methods  com¬ 
prise  (see  Figure  A-9).  These  entities  are  shown  in  Table  A-3. 
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ORGANIZATION 


ORGANIZATION-ASSOCIATION 


ORDINATE  ORGANIZATION  IDENTIFIER  (FK) 
SUBORDINATE  ORGANIZATION  IDENTIFIER  (FK) 
ORGANIZATION-ASSOCIATION  IDENTIFIER 


ORGANIZATION-ASSOCIATION  CONFIGURATION  CATEGORY  CODE 
ORGANIZATION-ASSOCIATION  EFFECTIVE  CALENDAR  DATE-TIME 
ORGANIZATION-ASSOCIATION  END  CALENDAR  DATE-TIME 
ORGANIZATION-ASSOCIATION  REINFORCEMENT  CATEGORY  CODE 
ORGANIZATION-ASSOCIATION  TYPE  CODE 


is  the  subject  of 


is  the  object  of 


ORGANIZATION  IDENTIFIER 


IDENTIFICATION-FRIEND-FOE  CODE  (FK) 

ORGANIZATION  CATEGORY  CODE 
ORGANIZATION  CLASSIFICATION  CODE 
ORGANIZATION  DESCRIPTION  TEXT 
ORGANIZATION  DURATION  TYPE  CODE 
ORGANIZATION  PRIMARY  ACTIVITY  CODE 
ORGANIZATION  TYPE  CODE 


may  be  an 


ENEMY-ORGANIZATION 


ENEMY-ORGANIZATION  INTELLIGENCE  KEY  IDENTIFIER 


ORGANIZATION  IDENTIFIER  (FK) 


originates 
is  described  by 


,  applies  to 

IDENTIFICATION-FRIEND-FOE 

'  IDENTIFICATION-FRIEND-FOE  CODE 


ORGANIZATION  CLASSIFICATION  CODE 


UNIFORMED-SERVICE-ORGANIZATION 

USO  ORGANIZATION  Identifier  (FK) 


ORGANIZATION-OPERATIONAL-STATUS 


ORGANIZATION  IDENTIFIER  (FK) 

ORGANIZATION-OPERATIONAL-STATUS  IDENTIFIER 

Originating  MATERIEL  IDENTIFIER 
Originating  ORGANIZATION  IDENTIFIER  (FK) 

Originating  PERSON  IDENTIFIER 

ORGANIZATION-OPERATIONAL-STATUS  CONDITION  CODE 
ORGANIZATION-OPERATIONAL-STATUS  PROTECTIVE  POSTURE  CODE 
ORGANIZATION-OPERATIONAL-STATUS  RADIATION  LEVEL  CODE 
ORGANIZATION-OPERATIONAL-STATUS  VULNERABILITY  CODE 
ORGANIZATION-OPERATIONAL-STATUS  PROTECTION  LEVEL  CODE 
ORGANIZATION-OPERATIONAL-STATUS  CURRENT  ACTIVITY  CODE 
ORGANIZATION-OPERATIONAL-STATUS  CALENDAR  DATE-TIME 
ORGANIZATION-OPERATIONAL-STATUS  AIR  DEFENSE  WEAPONS  CONTROL  CODE 
ORGANIZATION-OPERATIONAL-STATUS  AIR  DEFENSE  WARNING  CODE 
ORGANIZATION-OPERATIONAL-STATUS  DESCRIPTION  TEXT 
ORGANIZATION-OPERATIONAL-STATUS  COMBAT  INTENSITY  CODE 
ORGANIZATION-OPERATIONAL-STATUS  COMBAT  EFFECTIVENESS  CODE 
ORGANIZATION-OPERATIONAL-STATUS  COMBAT  READINESS  CODE 
ORGANIZATION-OPERATIONAL-STATUS  PROJECTED  ACTIVITY  CODE 
ORGANIZATION-OPERATIONAL-STATUS  READINESS  CONDITION  CODE 
ORGANIZATION-OPERATIONAL-STATUS  REINFORCEMENT  CODE 


UNIFORMED-SERVICE-ORGANIZATION  Category  Code 


UNIFORMED-SERVICE-ORGANIZATION  Category  Code 


MILITARY-UNIT 


Military  Unit  ORGANIZATION  Identifier  (FK) 


MILITARY-UNIT  ALTERNATE  IDENTIFIER 
MILITARY-UNIT  CURRENT  ACTIVITY  CODE 
MILITARY-UNIT  DEFENSE  READINESS  CONDITION  CODE 
MILITARY-UNIT  NUCLEAR  WEAPON  INDICATOR  CODE 
MILITARY-UNIT  REFERENCE  NUMBER  IDENTIFIER 
MILITARY-UNIT  TROOP  PROGRAM  IDENTIFIER 
MILITARY-UNIT  CONDITION  CODE 
MILITARY-UNIT  MAJOR  INDICATOR  CODE 
MILITARY-UNIT  FORCE  TYPE  CODE 
MILITARY-UNIT  FOREIGN  MILITARY  TRANSLATED  NAME 
MILITARY-UNIT  POSITION  STATUS  CODE 
MILITARY-UNIT  IDENTIFIER 
MILITARY-UNIT  DEFENSE  ALERT  CODE 


FigureA-9.  AlCDM  Relationship  between  MILITARY-UNIT  and  ORGANIZATION 


Table  A-3.  AlCDM  entities  that  align  to  the  Unit  class  at  the  State  level 


AlCDM  Entity 

Suggested  By 
OMSC  Method 

Relation  to  MILITARY-UNIT 

•  POINT 

•  MEASURED- 
ELEVATION-POINT 

getLocationO 

A  MILITARY-UNIT  is  associated  with  a  CONTROL- 
FEATURE,  which  has  an  associated  LOCATION. 
GEOMETRIC-SPATIAL-ELEMENT  is  a  subtype  of 
LOCATION.  POINT  Isa  subtype  of  GEOMETRIC- 
SPATIAL-ELEMENT.  MEASURED-ELEVATION-POINT  Isa 
subtype  of  POINT.  See  Figure  A-2. 

None. 

getVelocityO 

N/A 

•  ORGANIZATION 

•  MILITARY-UNIT 

getIDO 

MILITARY-UNIT  is  a  subtype  of  ORGANIZATION. 

•  ORGANIZATION 

•  ORGANIZATION- 
ASSOCIATION 

getSideO 

ORGANIZATION  is 
also  necessary 
as  a  link  to  other 
entities 

An  ORGANIZATION  has  a  hierarchical  structure 
defined  by  relationships  with  the  ORGANIZATION- 
ASSOCIATION  entity.  See  Figure  A-9. 
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AICDM  Entity 

Suggested  By 
OMSC  Method 

Relation  to  MILITARY-UNIT 

ORGANIZATION- 

OPERATIONAL-STATUS 

•  getPostureO 

•  getStatusO 

A  MILITARY-UNIT  is  described  by  an  ORGANIZATION 
OPERATIONAL  STATUS.  See  Figure  A-9. 

TASK 

getMissionO 

A  MILITARY-UNIT  has  a  MISSION,  which  is  composed 
of  one  or  moreTASKs.  See  Figure  A-8. 

MILITARY-UNIT 

getEchelonO 

Identical  (the  same  entity) 

•  POINT 

•  MEASURED- 
ELEVATION-POINT 

moveO 

A  MILITARY-UNIT  is  associated  with  a  CONTROL- 
FEATURE,  which  has  an  associated  LOCATION.  A 
subtype  of  LOCATION  isPOINT  (for  two  dimen¬ 
sions);  a  subtype  of  POINT  is  MEASURED-POINT  (for 
three  dimensions).  See  Figure  A-2. 

•  ORGANIZATION-TYPE- 
ORGANIZATION 

HOLDING  ESTIMATE 

•  PERSON-TYPE- 
PERSON  HOLDING 
ESTIMATE 

determineAttritionO 

A  MILITARY-UNIT  has  associated  PERSON-TYPE  and 
MATERIEL-ITEM  entities.  The  association  records 
the  number  of  entities  of  the  type.  See  Figure  A-4 
and  Figure  A-7. 

The  degree  of  Entity  level  alignment  of  the  Unit  elass  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (51%). 


A.i.i.i.ThegetLocation()  Method  (State  Level) 

The  OMSC  defines  the  result  of  the  getLocationO  method  as  “typieally  ...  eenter  of  mass  or 
some  other  point  loeation....”  [HB  1998A]  The  following  ambiguities  in  this  deseription 
limit  the  alignment  analysis: 

•  Apparently,  loeation  ean  be  something  other  than  a  point.  It  might,  for  example,  be  an 
arbitrary  geometrieal  shape  eneompassing  an  entire  unit,  rather  than  the  unit’s  eenter 
of  mass. 

We  ignore  the  eases  where  loeation  is  not  a  point,  and  align  getLocationO  to  those 
AICDM  entities  that  model  points.  The  rationale  for  this  deeision  is  that  the  OMSC 
has  a  method  UnitGeometry.getShapeO,  whieh  returns  a  unit’s  shape.  To  inelude  geomet- 
rieal  shapes  as  possible  values  of  getLocationO  would  be  redundant. 

•  The  OMSC  does  not  state  how  eenter  of  mass  is  eomputed.  The  implieation  of  this 
ambiguity  is  that  a  unit’s  loeation  eannot  be  ealeulated  based  on  knowledge  of  its 
shape. 

The  OMSC  has  a  standard  objeet  Location.  The  result  of  the  getLocationO  method  aligns  to 
the  AICDM  at  the  State  level  to  the  same  degree  that  Location  aligns  to  the  AICDM  (37%). 
See  Seetion  A.3.  Figure  A-10  shows  the  AICDM  struetures  for  speeifying  the  loeation  of 
military  units. 
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ORGANIZATION 


ORGANIZATION  IDENTIFIER 


IDENTIFICATION-FRIEND-FOE  CODE 
Principal  EQUIPMENT-TYPE  Code 
ORGANIZATION  CATEGORY  CODE 
ORGANIZATION  CLASSIFICATION  CODE 
ORGANIZATION  DESCRIPTION  TEXT 
ORGANIZATION  DURATION  TYPE  CODE 
ORGANIZATION  PRIMARY  ACTIVITY  CODE 
ORGANIZATION  TYPE  CODE 


ORGANIZATION-FEATURE 

ORGANIZATION-FEATURE  IDENTIFIER 
ORGANIZATION  IDENTIFIER  (FK) 
FEATURE  IDENTIFIER  (FK) 


ORGANIZATION-FEATURE  ROLE  CODE 
ORGANIZATION-FEATURE  BEGIN  CALENDAR  DATE-TIME 
ORGANIZATION-FEATURE  END  CALENDAR  DATE-TIME 


ORGANIZATION-LOCATION  IDENTIFIER 
LOCATION  IDENTIFIER  (FK) 
ORGANIZATION  IDENTIFIER  (FK) 


ORGANIZATION-LOCATION  ASSOCIATION  CODE 
ORGANIZATION-LOCATION  DURATION  QUANTITY 
ORGANIZATION-LQCATION  EFFECTIVE  CALENDAR  DATE 
ORGANIZATION-LOCATION  EFFECTIVE  TIME 
ORGANIZATION-LOCATION  REASON  TEXT 
ORGANIZATION-LOCATION  SEQUENCE  IDENTIFIER 


(^ORGANIZATION  CLASSIFICATION  CODE 


UNIFORMED-SERVICE-ORGANIZATION _ 

'uso  ORGANIZATION  Identifier  (FK) 

UNIFORMED-SERVICE-ORGANIZATION-COMPONENT-TYPE  CODE 
UNIFORMED-SERVICE-ORGANIZATION  Category  Code 


UNIFORMED-SERVICE-ORGANIZATION  Category  Code 


MILITARY-UNIT 


Military  Unit  ORGANIZATION  Identifier  (FK) 


UNIT-LEVEL  CODE 

MILITARY-UNIT  ALTERNATE  IDENTIFIER 
MILITARY-UNIT  CURRENT  ACTIVITY  CODE 
MILITARY-UNIT  DEFENSE  READINESS  CONDITION  CODE 
MILITARY-UNIT  NUCLEAR  WEAPON  INDICATOR  CODE 
MILITARY-UNIT  REFERENCE  NUMBER  IDENTIFIER 
MILITARY-UNIT  TROOP  PROGRAM  IDENTIFIER 
MILITARY-UNIT  CONDITION  CODE 
MILITARY-UNIT  MAJOR  INDICATOR  CODE 
MILITARY-UNIT  FORCE  TYPE  CODE 
MILITARY-UNIT  FOREIGN  MILITARY  TRANSLATED  NAME 
MILITARY-UNIT  POSITION  STATUS  CODE 
MILITARY-UNIT  IDENTIFIER 
MILITARY-UNIT  DEFENSE  ALERT  CODE 


LOCATION  IDENTIFIER 
LOCATION  CATEGORY  CODE 
.  LOCATION  NAME 


^LOCATION  CATEGORY  CODE 


GEOMETRIC-SPATIAL-ELEMENT 


LOCATION  IDENTIFIER  (FK) 
GEOMETRIC-SPATIAL-ELEMENT  TYPE  CODE 
GEOMETRIC-SPATIAL-ELEMENT  EXTRACTION  DATE 
ORGANIZATION  IDENTIFIER  (FK) 


GEOMETOIC-SPATIAL-ELEMENTTYPE  CODE 


LOCATION  IDENTIFIER  (FK) 

HORIZONTAL-REFERENCE-DATUM  code 
VERTICAL-REFERENCE-DATUM  code 
POINT  LATITUDE  COORDINATE 
POINT  LONGITUDE  COORDINATE 
POINT  ELEVATION  TYPE  CODE 
POINT  HORIZONTAL  PRECISION  QUANTITY 


FEATURE-LQCATION 


FEATURE-LOCATIQN  IDENTIFIER 
FEATURE  IDENTIFIER  (FK) 
LOCATION  IDENTIFIER  (FK) 


FEATURE-LOCATION  TYPE  CODE 
FEATURE-LOCATION  DURATION  QUANTITY 
FEATURE-LOCATION  EFFECTIVE  CALENDAR  DATE-TIME 
FEATURE-LOCATION  SEQUENCE  IDENTIFIER 
FEATURE-LOCATIQN  ACCURACY  EVALUATION  CODE 
FEATURE-LOCATION  DESCRIPTION  TEXT 
FEATURE-LOCATION  END  CALENDAR  DATE-TIME 
FEATURE-LOCATION  RELIABILITY  EVALUATION  CODE 


FEATURE  IDENTIFIER 


IDENTIFICATION-FRIEND-FOE  CODE 

FEATURE-TYPE  IDENTIFIER 

FEATURE  CATEGORY  CODE 

FEATURE  NAME 

FEATURE  DESCRIPTION  TEXT 

FEATURE  EXISTENCE  END  CALENDAR  DATE-TIME 

FEATURE  EXISTENCE  BEGIN  CALENDAR  DATE-TIME 

FEATURE  ENEMY  ACTIVITY  CODE 

FEATURE  COUNTERMEASURE  CODE 


FEATURE  CATEGORY  CODE 


CONTROL-FEATURE _ 

'feature  identifier  (FK) 


AIRSPACE  IDENTIFIER 
CONTROL-FEATURE  ROLE  CODE 
CONTROL-FEATURE  CATEGORY  CODE 
CONTROL-FEATURE  SURVEY  DATUM  CODE 
CONTROL-FEATURE  SURVEY  POINT  ACCURACY  CODE 
AIRSPACE-SECTOR  IDENTIFIER 


Figure  A-10.  AlCDM  Structures  for  Locating  Military  Units 


A.i.i.2.ThegetVelocity()  Method  (State  Level) 


This  method’s  description  indicates  that  it  returns 
does  not  model  motion  of  organizations,  nor  does 
and  FAN-AREA  have  an  ORIENTATION  ANGLE  attribute, 


the  velocity  of  a  Unit.  The  AICDM 
it  model  orientation.  (REGULAR -A REA 
but  the  attribute  refers  to  the  angle  of 
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the  geometric  figure,  not  the  direction  component  of  the  figure’s  velocity.)  There  is  no 
alignment  at  the  State  level  (0%)  between  getVelocityO  and  the  AICDM.^ 

A.i.i.3.ThegetlD()  Method  (State  Level) 

The  following  ambiguities  in  the  description  of  the  getlD()  method  limit  alignment  analy¬ 
sis: 


•  There  is  no  indication  of  standards  for  assigning  IDs  to  units.  Standards  might  come 
from  such  considerations  as  the  following: 

-  How  will  the  ID  be  used?  For  example,  if  it  will  be  displayed  on  a  screen,  it 
must  be  fairly  short. 

-  Should  it  relate  to  real  unit  identifiers? 

The  alignment  analysis  assumes  only  that  IDs  must  be  unique.  AICDM  IDs  must  be 
IDs  of  real  units;  OMSC’s  need  not.  To  achieve  perfect  alignment  might  require  some 
automated  translation  system  that  maps  between  the  schemes. 

There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  getIDO  method.  The  AICDM  has  many  attributes  that  can  represent  an  ID  (see 
Figure  A-9).  The  getlD()  method  might  map  to  any  of  the  following  AICDM  attributes  of 
MILITARY-UNIT: 

•  MILITARY-UNIT  ALTERNATE  IDENTIFIER 

•  MILITARY-UNITREFERENCE  NUMBER  ID 

•  MILITARY-UNITTROOP  PROGRAM  IDENTIFIER 

•  MILITARY-UNIT  FOREIGN  MILITARY  TRANSLATED  NAME 

•  MILITARY-UNIT  IDENTIFIER 

The  getIDO  method  might  also  map  to  the  ORGANIZATION-IDENTIFIER  attribute  of 
ORGANIZATION. 

The  AICDM  and  the  OMSC  do  not  align  perfectly  with  respect  to  getIDO  because  it  is  not 
clear  which  of  these  attributes  models  the  type  of  ID  returned  by  getlD().  This  cannot  be 
determined  without  more  detail  from  the  OMSC. 


^  There  is  a  proposal  to  add  velocity  and  orientation  attributes  to  the  pertinent  entities  in  the  AICDM. 
These  additions  will  support  the  OMSC  requirements  associated  with  the  getVelocityO  method. 
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A.i.i.4.The  getSideO  Method  (State  Level) 


The  following  ambiguities  in  the  deseription  of  the  getSideO  method  limit  alignment 
analysis: 

•  There  is  no  indieation  of  the  maximum  number  of  sides  that  must  be  supported.  At 
one  time  it  was  assumed  that  the  only  sides  would  be  “blue”  and  “red”,  but  with  the 
advent  of  eoalition  warfare  the  number  of  possible  sides  has  grown.  Note  that  WAR- 
SIM  has  a  eontraetual  requirement  to  support  at  least  36  different  sides. 

The  alignment  analysis  does  not  assume  a  limit  on  the  number  of  sides  that  must  be 
modeled. 

There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  with  respeet  to  the  getSideO  method.  The  alignment  is  not  perfeet  beeause  the 
built-in  attributes  of  the  AICDM  express  a  more  limited  model  of  sides  than  that  of  the 
OMSC: 

•  An  ORGANIZATION  has  an  IDENTIFICATION-FRIEND-FOE  CODE  attribute  (a  foreign  key).® 
This  is  more  limited  than  the  eoneept  of  arbitrary  eoalitions  and  alignments  required 
by  the  OMSC. 

•  An  ORGANIZATION  “pertains  to”  one  or  more  eountries,  and  an  ENEMY-ORGANIZATION  is 
a  subtype  of  ORGANIZATION  (see  Figure  A-9).  However,  this  relationship  eannot  model 
more  than  two  sides  (friend  and  foe). 

The  alignment  analysis  uses  the  following  approaeh  to  model  a  faetion  (or  eoalition). 
Eaeh  faetion  is  modeled  as  an  ORGANIZATION.  The  name  of  this  ORGANIZATION  entity 
(given  in  the  ORGANIZATION-NAME  entity)  is  the  name  of  the  faetion.  The  eonstituents  of 
the  faetion  are  assoeiated  with  the  side  through  the  ORGANIZATION-ASSOCIATION  entity, 
whieh  ean  form  a  hierarehieal  relationship  of  organizations.  See  Figure  A-2. 

Figure  A- 11  shows  an  example  of  entity  instanees  populating  AICDM  tables.  These  in- 
stanees  represent  two  faetions:  “Red  team”  and  “Blue  team”.  Red  team  eonsists  of  two 
member.  Red  member  1  and  Red  member  2.  Blue  team  eonsists  of  3  members.  Blue 
members  1  through  3. 


^  Previous  versions  of  the  AICDM  modeled  this  as  an  attribute  of  each  of  the  battlefield  objects.  How¬ 
ever,  in  order  to  make  re-use  of  the  attributes  more  readily  these  attributes  have  been  externalized  as  an 
independent  entity.  The  current  attributes  will  be  replaced  by  a  non-identifying  relationship  from  this 
entity  to  the  ones  requiring  those  types  of  values. 
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ORGANIZATION  | 

ORGANIZATION-IDENTIFIER 

1 

2 

3 

4 

5 

6 


ORGANIZATION-ASSOCIATION  ] 


ORGANIZATION-IDENTIFIER 

SUBORDINATE-ORGANIZATION-IDENTIFIER 

1 

2 

1 

3 

4 

5 

4 

6 

5 

7 

ORGANIZATION-NAME  | 

ORGANIZATION-IDENTIFIER 

ORGANIZATION-NAME  TEXT 

1 

Red  Team 

2 

Red  member  1 

3 

Red  member  2 

4 

Blue  Team 

5 

Blue  member  1 

6 

Blue  member  2 

7 

Blue  member  3 

Figure  A- 11.  Example  of  Faction  Representation 

For  brevity,  Figure  A- 11  omits  several  attribute  values.  It  shows  only  how  organizations 
ean  be  arranged  to  form  a  eoalition.  There  is  still  no  speeifieation  of  enmity,  or  laek 
thereof,  between  the  two  eoalitions. 


A  problem  with  using  this  eonvention  for  modeling  sides  is  that  the  ORGANIZATION  TYPE  ^alue 
CODE  attribute  has  no  value  that  denotes  a  eoalition  or  faetion.  Neither,  for  that  matter, 
does  the  ORGANIZATION-ASSOCIATION  TYPE  CODE  attribute.  Possible  values  inelude  HAS 


FULL  COMMAND  OVER,  REPORTS  TO,  CONTROLS,  and  IS  IN  DIRECT  SUPPORT  OF,  depending 
on  the  type  of  eoalition. 


A.i.i.5.ThegetPosture()  Method  (State  Level) 

The  following  ambiguities  in  the  deseription  of  the  getPostureO  method  limit  alignment 
analysis: 

•  Possible  postures  are  deseribed  using  a  few  examples.  The  list  eannot  be  regarded  as 
eomplete. 

The  alignment  analysis  attempts  to  use  the  doetrinal  interpretation  of  the  term. 

There  is  a  low  degree  of  State  level  alignment  (25%)  between  the  AlCDM  and  the 
OMSC  with  respeet  to  the  getPostureO  method.  This  statement  is  based  on  the  observation 
that  few  AlCDM  attributes  model  posture  as  the  term  is  generally  used  in  M&S  systems; 
and  those  attributes  that  model  posture  do  so  to  a  limited  degree.  The  following  is  a  list  of 
eandidate  AlCDM  attributes  (see  Figure  A-9): 

•  ORGANIZATION-OPERATIONAL-STATUS  PROTECTIVE  POSTURE  CODE 

•  ORGANIZATION-OPERATIONAL-STATUS  CURRENT  ACTIVITY  CODE 

•  MILITARY-UNIT  CURRENT  ACTIVITY  CODE 
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However,  none  of  these  names  seems  adequate  to  aoeommodate  the  full  range  of  postures 
suggested  by  the  OMSC’s  deseription  of  the  method. 


An  examination  of  the  domains  of  the  above  attributes  eonfirms  the  previous  paragraph,  [value 
Eaeh  ean  model  some  types  of  postures.  Not  even  the  eombined  set  ean  model  all. 


A.1.1.6. The  getStatusO  Method  (State  Level) 

The  following  ambiguities  in  the  deseription  of  the  getStatusO  method  limit  alignment 
analysis: 

•  Possible  status  are  deseribed  using  a  few  examples.  The  list  eannot  be  regarded  as 
eomplete. 

The  alignment  analysis  attempts  to  use  doetrinal  interpretation  of  the  term. 

There  is  a  low  degree  of  State  level  alignment  (25%)  between  the  AICDM  and  the 
OMSC  with  respeet  to  the  getStatusO  method.  This  statement  is  based  on  the  observation 
that  few  AICDM  attributes  model  status  as  the  term  is  generally  used  in  M&S  systems; 
and  those  attributes  that  model  status  do  so  to  a  limited  degree.  In  the  AICDM  the  follow¬ 
ing  attributes  are  possibilities,  but  as  with  getPostureO  none  of  the  names  seems  adequate 
to  aoeommodate  the  full  range  of  statuses  suggested  by  the  OMSC’s  deseription  of  the 
method  (see  Figure  A-9): 

•  ORGANIZATION-OPERATIONAL-STATUS  COMBAT  EFFECTIVENESS  CODE 

•  ORGANIZATION-OPERATIONAL-STATUS  COMBAT  READINESS  CODE 

•  MILITARY-UNIT.MILITARY-UNIT  CURRENT  READINESS  CONDITION  CODE 

•  MILITARY-UNIT  DEFENSE  READINESS  CONDITION  CODE 


A  problem  with  aligning  these  attributes  to  the  result  of  the  getStatusO  method  is  that  the  [value 
attribute  domains  are  enumerated  eode  values.  By  eontrast,  the  results  of  getStatusO  ean 
be  a  numerie  value  (e.g.,  a  pereent  effeetiveness). 


Furthermore,  an  examination  of  the  domains  of  the  above  attributes  eonfirms  that  the  [value 
attributes  eannot  model  a  wide  range  of  statuses. 


A.i.i.7.ThegetMission()  Method  (State  Level) 

There  is  a  medium  degree  of  State  level  alignment  (50%)  between  the  AICDM  and  the 
OMSC  with  respeet  to  the  getMIsslonO  method  (see  Figure  A- 12).  In  M&S  systems,  an 
OMSC  mission  is  prose.  It  therefore  aligns  with  the  TASK-DESCRIPTION-TEXT  attribute  of 
an  AICDM  TASK  entity.  However,  the  alignment  is  unidireetional.  An  AICDM  TASK  may 
be  a  hierarehy.  This  hierarehy  might  map  to  an  AICDM  mission  using  some  standard  al¬ 
gorithm  for  amalgamating  the  task  deseriptions  in  the  hierarehy,  but  the  original  strueture 
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couldn’t  necessarily  be  recovered  from  getMission().  In  other  words,  the  AICDM  can  model 
the  OMSC,  but  not  vice  versa. 


ORGANIZATION 


ORGANIZATION  IDENTIFIER 


IDENTIFICATION-FRIEND-FOE  CODE 
Principal  EQUIPMENT-TYPE  Code 
ORGANIZATION  CATEGORY  CODE 
ORGANIZATION  CLASSIFICATION  CODE 
ORGANIZATION  DESCRIPTION  TEXT 
ORGANIZATION  DURATION  TYPE  CODE 
ORGANIZATION  PRIMARY  ACTIVITY  CODE 
ORGANIZATION  TYPE  CODE 


is  referenced  by  /rev/ 
PLAN-ORGANIZATION 


PLAN _ 

PLAN  IDENTIFIER 
PLAN  NAME 

PLAN  VERSION  IDENTIFIER 

PLAN  TYPE  CODE 

PLAN  COMMANDER  INTENT  TEXT 

PLAN  PURPOSE  CODE 

PLAN  SUBJECT  TEXT 

PLAN  TEXT 


is  part  of 


ORGANIZATION  IDENTIFIER  (FK) 

PLAN  IDENTIFIER  (FK) 

PLAN-ORGANIZATION  IDENTIFIER 

PLAN-ORGANIZATION  PRIORITY  CODE 
PLAN-ORGANIZATION  ROLE  CODE 
PLAN-ORGANIZATION  BEGIN  CALENDAR  DATE-TIME 
PLAN-ORGANIZATION  END  CALENDAR  DATE-TIME 


contains 


PLAN-ACTION 


PLAN  IDENTIFIER  (FK) 

ACTION  IDENTIFIER 
PLAN-ACTION  IDENTIFIER 

PLAN-ACTION  PLANNED  END  CALENDAR  DATE-TIME 
PLAN-ACTION  PLANNED  BEGIN  CALENDAR  DATE-TIME 
PLAN-ACTION  ROLE  CODE 


TASK-PLAN 


ORGANIZATION  CLASSIFICATION  CODE 


TASK-PLAN  IDENTIFIER 
PLAN  IDENTIFIER  (FK) 
TASK  IDENTIFIER  (FK) 


UNIFORMED-SERVICE-ORGANIZATION 


USO  ORGANIZATION  Identifier  (FK) 


UNIFORMED-SERVICE-ORGANIZATION-COMPONENT-TYPE  CODE 
UNIFORMED-SERVICE-ORGANIZATION  Category  Code 


UNIFORMED-SERVICE-ORGANIZATION  Category  Code 


MILITARY-UNIT 


Military  Unit  ORGANIZATION  Identifier  (FK) 


UNIT-LEVEL  CODE 

MILITARY-UNIT  ALTERNATE  IDENTIFIER 
MILITARY-UNIT  CURRENT  ACTIVITY  CODE 
MILITARY-UNIT  DEFENSE  READINESS  CONDITION  CODE 
MILITARY-UNIT  NUCLEAR  WEAPON  INDICATOR  CODE 
MILITARY-UNIT  REFERENCE  NUMBER  IDENTIFIER 
MILITARY-UNIT  TROOP  PROGRAM  IDENTIFIER 
MILITARY-UNIT  CONDITION  CODE 
MILITARY-UNIT  MAJOR  INDICATOR  CODE 
MILITARY-UNIT  FORCE  TYPE  CODE 
MILITARY-UNIT  FOREIGN  MILITARY  TRANSLATED  NAME 
MILITARY-UNIT  POSITION  STATUS  CODE 
MILITARY-UNIT  IDENTIFIER 
MILITARY-UNIT  DEFENSE  ALERT  CODE 


TASK-PLAN  BEGIN  CALENDAR  DATE-TIME 
TASK-PLAN  END  CALENDAR  DATE-TIME 
TASK-PLAN  FREQUENCY  RATE 
TASK-PLAN  PRIORITY  CODE 
TASK-PLAN  ROLE  CODE 
^ - 

I  is  part  of 

TASK 

TASK  IDENTIFIER 

_  TASK-TYPE  IDENTIFIER 

TASK  DESCRIPTION  TEXT 
TASK  NAME 
TASK  Category  Code 


participates  in 


is  used  to  accomplish 


MISSION-TASK 


is  participant  in 


TASK-ASSOCIATION 


MISSION  IDENTIFIER  (FK) 
TASK  IDENTIFIER  (FK) 


MISSION-TASK  Role  Code 


Ordinate  TASK  Identifier  (FK) 
Subordinate  TASK  Identifier  (FK) 
TASK-ASSOCIATION  BEGIN  DATE 


TASK-ASSOCIATION  END  DATE 
TASK-ASSOCIATION  REASON  CODE 


is  referenced  in 


MISSION-ORGANIZATION 


requires 


MISSION  IDENTIFIER  (FK) 

ORGANIZATION  IDENTIFIER  (FK) 
MISSION-ORGANIZATION  IDENTIFIER 

MISSION-ORGANIZATION  ROLE  CODE 
MISSION-ORGANIZATION  BEGIN  CALENDAR  DATE-TIME 
MISSION-ORGANIZATION  END  CALENDAR  DATE-TIME 


is  controlled  by 


MISSION  IDENTIFIER 


MISSION-AREA  TYPE  CODE 
OPERATIONAL-SCENARIO  Identifier 
MISSION  CATEGORY  CODE 
MISSION  TYPE  CODE 

MISSION  EFFECTIVE  CALENDAR  DATE-TIME 
MISSION  CLASSIFICATION  CODE 


Figure  A- 12.  AICDM  Structures  for  Missions  and  Tasks 


A.i.i.8.ThegetEchelon()  Method  (State  Level) 

There  is  perfect  State  level  alignment  (100%)  between  the  AICDM  and  the  OMSC  with 
respeet  to  the  getEchelonO  method.  The  return  value  of  getEchelonO  maps  to  the  MILITARY- 
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UNIT  UNIT-LEVEL  CODE  attribute  of  the  MILITARY-UNIT  entity  (see  Figure  A-9).  The  values 
for  this  attribute  eover  all  the  standard  terms  for  eehelons.  (We  assume  that  M&S  systems 
use  standard  terms  as  well.) 


A.1.1.9.  The  moveO  Method  (State  Level) 

The  following  ambiguities  in  the  deseription  of  the  move()  method  limit  alignment  analy¬ 
sis: 

•  The  speeifieation  does  not  state  the  parameters  of  the  method.  How  is  the  next  loea- 
tion  determined?  Without  this  knowledge,  alignment  analysis  eannot  determine  if  all 
reasonable  variations  of  movement  ean  be  modeled  in  the  AICDM.  An  example  of 
one  that  eould  not  be  modeled  is  “move  forward”,  beeause  the  AICDM  does  not 
model  unit  orientation. 

•  The  OMSC  states  that  move()  “advanees  a  unit  towards  its  next  loeation”.  This  seems 
to  imply  that  the  next  loeation  is  known  in  advanee.  If  so,  parameters  might  not  be 
needed.  But  the  OMSC  has  no  method  to  speeify  a  next  loeation. 

•  The  OMSC  does  not  speeify  a  model  for  ehanges  to  a  unit’s  supplies  and  readiness  as 
eaused  by  movement.  Movement  ean  drain  fuel,  reduee  troop  readiness,  ete.  It  is  im¬ 
possible  to  determine  if  the  AICDM  eontains  all  the  attributes  neeessary  to  model  the 
effeets  of  movement  in  an  M&S  system. 

This  is  a  behavioral  method.  The  following  are  some  possible  state  ehanges: 

•  A  ehange  to  a  unit’s  loeation.  The  AICDM  is  able  to  model  this  ehange,  beeause  an 
ORGANIZATION  has  (via  a  CONTROL-FEATURE)  a  LOCATION  (see  Figure  A-10).  The  asso- 
eiation  is  through  relationships  involving  an  entity  ORGANIZATION-FEATURE,  whieh  has 
attributes  ORGANIZATION-FEATURE  BEGIN  CALENDAR  DATE-TIME  and  ORGANIZATION- 
FEATURE  END  CALENDAR  DATE-TIME.  These  attributes  are  partieularly  useful  in  keeping 
a  history  of  state,  if  desired. 

•  A  ehange  to  a  unit’s  supplies.  The  FIOLDING  entities,  or  assoeiations  to  MATERIEL  enti¬ 
ties,  ean  model  ehanges  in  these  quantities.  See  Figure  A-13. 

•  A  ehange  to  the  eondition  of  a  unit’s  supplies  and  personnel  (e.g.,  equipment  break¬ 
age,  personnel  injuries).  If  the  M&S  system  reeords  individual  entities,  the  AICDM 
ean  model  these  ehanges.  If  the  M&S  system  models  only  quantities,  the  AICDM 
eannot  model  these  ehanges. 
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MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE 


MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE  IDENTIFIER 
ORGANIZATION  IDENTIFIER  (FK) 

MATERIEL-ITEM  IDENTIFIER  (FK) 


MEASURE-UNIT  CODE  (FK) 

MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE  ACCURACY  EVALUATION  CODE 
MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE  QUANTITY 
MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE  RELIABILITY  EVALUATION  CODE 
MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE  STATUS  CODE 
MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE  SUPPLY  RATE 
MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE  TYPE  CODE 
MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE  CALENDAR  DATE-TIME 
Reporting  ORGANIZATION  Identifier  (FK) 

MEASURE-UNIT  RATE  CODE  (FK) 


provides] 


is  inventoried  by 


may  be  included  in 


pertains  to 

i 

MEASURE-UNIT 

1 

MEASURE-UNIT  CODE 
MEASURE-UNIT  RATE  CODE 

ORGANIZATION 

1 

ORGANIZATION  IDENTIFIER 

IDENTIFICATION-FRIEND-FOE  CODE 
Principal  EQUIPMENT-TYPE  Code 
ORGANIZATION  CATEGORY  CODE 
ORGANIZATION  CLASSIFICATION  CODE 
ORGANIZATION  DESCRIPTION  TEXT 
ORGANIZATION  DURATION  TYPE  CODE 
ORGANIZATION  PRIMARY  ACTIVITY  CODE 
ORGANIZATION  TYPE  CODE 

MATERIEL-ITEM 


MATERIEL-ITEM  IDENTIFIER 


MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 

MATERIEL-ITEM 


COMMODITY  TYPE  CODE 
CONTROL  NUMBER  TYPE  CODE 
CRITICAL  APPLICATION  CODE 
DEMILITARIZATION  CODE 
DESCRIPTION  TEXT 
END  INDICATOR  CODE 
ESSENTIALITY  CODE 

FEDERAL  SUPPLY  SCHEDULE  IDENTIFIER 

FIRST  ARTICLE  TEST  CODE 

FOREIGN  PRODUCED  INDICATOR  CODE 

FREIGHT  INTEGRITY  CODE 

HIGH  DOLLAR  CODE 

NAME 

NET  CONTRACT  DUEIN  UNIT  QUANTITY 
NET  PURCHASE  ORDER  DUEIN  UNIT  QUANTITY 
PACKAGING  DATA  AVAILABILITY  CODE 
PREFERRED  INSPECTION  PLACE  CODE 
PREFERRED  INSPECTION  TYPE  CODE 
PRODUCTION  INDICATOR  CODE 
PRODUCTION  LEADTIME  DAYS  QUANTITY 
PROMPT  PAY  DAY  QUANTITY 
PURCHASE  DESCRIPTION  TEXT 
REFERENCE  NUMBER  IDENTIFIER 
SELECTIVELY  MANAGED  CODE 
SHELF  LIFE  QUANTITY 
SPECIAL  ACTION  IDENTIFIER 
STORAGE  REQUIREMENT  TEXT 
TYPE  CODE 


Figure  A-13.  AICDM  Structures  for  Specifying  Materiel  Holdings 

Of  these  state  ehanges,  the  OMSC  only  mentions  loeation  as  an  effeet  of  the  move() 
method. 

There  is  a  medium  degree  of  State  level  alignment  (50%)  between  the  AICDM  and  the 
OMSC  with  respeet  to  the  moved  method.  Assuming  that  movement  is  speeified  based  on 
either  relative  or  absolute  direetion,  it  seems  reasonable  to  eonelude  that  the  AICDM  ean 
model  half  of  all  movement  operations,  beeause  the  AICDM  ean  model  absolute  but  not 
relative  direetion. 

A.i.i.io.ThedetermineAttrition()  Method  (State  Level) 

The  following  ambiguities  in  the  deseription  of  the  determineAttritionO  method  limit  align¬ 
ment  analysis: 

•  The  OMSC  does  not  speeify  units  for  attrition  (pereentage?  absolute  values?  speeifie 
entities  removed?) 
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•  An  analysis  of  attrition  must  occur  with  respect  to  some  previous  state.  The  OMSC 
does  not  describe  how  that  state  is  specified.  It  would  have  to  'be  either  fixed  or 
specified  as  a  parameter. 

•  The  description  does  not  say  whether  invoking  the  method  actually  causes  the  attri¬ 
tion  or  just  calculates  a  value  that  connotes  attrition.  As  there  is  a  separate 
causeAttritionO  method,  determineAttritionO  probably  only  calculates  a  value. 

The  determineAttritionO  method  aligns  indirectly.  Attrition  is  calculated  relative  to  some  pre¬ 
vious  state,  based  on  predefined  unit  characteristics  that  are  deemed  to  be  attrition.  These 
characteristics  are  described  in  Section  .  The  determineAttritionO  method  aligns  to  the  same 
degree  as  the  causeAttritionO  method  (75%). 

A.1.2.  UnitGeometry  Class  (Entity  Level) 

The  UnitGeometry  class  describes  two  characteristics  of  a  unit:  shape  and  orientation.  Table 
A-4  shows  the  AICDM  entities  taken  from  the  Conceptual  level  view  of  a  unit  that  relate 
to  geometry. 


Table  A-4.  AICDM  entities  that  align  to  the  UnitGeometry  class  at  the  State  level 


AICDM  Entity 

Suggested  By 
OMSC 
Method 

Relation  to  MILITARY-UNIT 

SURFACE  and  its 
subtypes 

getShapeO 

A  MILITARY-UNIT  has  (via  a  CONTROL-FEATURE)  an  associ¬ 
ated  LOCATION.  GEOMETRIC-SPATIAL-ELEMENT  is  a  subtype 
of  LOCATION.  SURFACE  is  a  subtype  of  GEOMETRIC-SPATIAL- 
ELEMENT.  See  Figure  A-2  and  Figure  A- 14. 

The  degree  of  Entity  level  alignment  of  the  UnitGeometry  class  is  the  average  of  the  degrees 
of  alignment  of  its  methods  (50%). 
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LOCATION 


LOCATION  IDENTIFIER 

LOCATION  CATEGORY  CODE 
LOCATION  NAME 


LOCATION  CATEGORY  CODE 


GEOMETRIC-SPATIAL-ELEMENT 


LOCATION  IDENTIFIER  (FK) 


GEOMETRIC-SPATIAL-ELEMENT  TYPE  CODE 
GEOMETRIC-SPATIAL-ELEMENT  EXTRACTION  DATE 


5 


GEOMETRIC-SPATIAL-ELEMENT  TYPE  CODE 


LINE 


LOCATION  IDENTIFIER  (FK) 


is  defined  by 


POINT 


GEOMETRIC-VOLUME 


LOCATION  IDENTIFIER  (FK) 


GEOMETRIC-VOLUME  LOWER  LEVEL  ELEVATION  DIMENSION 
GEOMETRIC-VOLUME  TYPE  CODE 

GEOMETRIC-VOLUME  UPPER  LEVEL  ELEVATION  DIMENSION 


-SURFACE 


may  be  used  to  define 


may  be  a  reference  point  for 


LOCATION  IDENTIFIER  (FK) 


REFERENCE  POINT  (FK) 
SURFACE  TYPE  CODE 


may  be  used  to  define 


LOCATION  IDENTIFIER  (FK) 

HORIZONTAL-REFERENCE-DATUM  code 
VERTICAL-REFERENCE-DATUM  code 
POINT  LATITUDE  COORDINATE 
POINT  LONGITUDE  COORDINATE 
POINT  ELEVATION  TYPE  CODE 
POINT  HORIZONTAL  PRECISION  QUANTITY 


SURFACE  TYPE  CODE 


serves  as 


POINT  ELEVATION  TYPE  CODE 


REGULAR-AREA 
^LOCATION  IDENTIFIER  (FK) 

REGULAR-AREA  TYPE  CODE 
REGULAR-AREA  MAJOR  DIMENSION 
REGULAR-AREA  MINOR  DIMENSION 
REGULAR-AREA  ORIENTATION  ANGLE 


LOCATION  IDENTIFIER  (FK) 
LINE-POINT  SEQUENCE  IDENTIFIER 


POINT  (FK) 


6 


REGULAR-AREA  TYPE  CODE 


ELLIPSE-AREA 


RECTANGLE-AREA 


LOCATION  IDENTIFIER  (FK) 


LOCATION  IDENTIFIER  (FK) 


MEASURED-ELEVATION-POINT 


LOCATION  IDENTIFIER  (FK) 

MEASURED-ELEVATION-POINT  ELEVATION  DIMENSION 
MEASURED-ELEVATION-POINT  PRECISION  QUANTITY 
MEASURED-ELEVATION-POINT  TYPE  CODE 


GEOMETRIC-VOLUME-SURFACE 


SURFACE  LOCATION  IDENTIFIER  (FK) 
GEOMETRIC  VOLUME  LOCATION  IDENTIFIER  (FK) 


Figure  A-14.AICDM  Structures  for  Specifying  Surfaces 

A.i.2.i.ThegetShape()  Method  (State  Level) 

The  following  ambiguities  in  the  deseription  of  the  getShapeO  method  limit  alignment 
analysis: 

•  The  OMSC  does  not  indieate  the  nature  or  generality  of  bounding  shapes. 

The  AICDM  has  a  rieh  set  of  possible  shapes  for  a  unit.  It  seems  safe  to  assume  that 
the  AICDM  ean  model  any  shape  that  getShapeO  would  return,  (the  AICDM  is  rieher 
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in  two  than  in  three  dimensions,  but  there  is  no  indieation  that  getShapeO  will  return 
any  areane  three  dimensional  shapes.) 

There  is  perfect  State  level  alignment  (100%)  between  the  AICDM  and  the  OMSC  with 
respeet  to  the  getShapeO  method.  The  return  value  of  the  getShapeO  method  maps  to  a  sub- 
type  of  SURFACE. 

A.i.2.2.ThegetOrientation()  Method  (State  Level) 

There  is  no  State  level  alignment  (0%)  between  the  AICDM  and  the  OMSC  with  respeet 
to  the  getOrientationO  method.  The  AICDM  does  not  model  unit  orientation.  The 
getOrientationO  method  does  not  align  to  any  AICDM  entities  or  attributes. 


A.1.3.  Intel  Class  (Entity  Level) 


Table  A-5.  AICDM  entities  that  align  totheintel  class  at  the  State  level 


AICDM  Entity 

Suggested  By 
OMSC 
Method 

Relation  to  MILITARY-UNIT 

SENSOR-TYPE 

collectO 

A  MILITARY-UNIT  has  associated  MATERIEL-ITEM  entities; 
the  association  records  the  number  of  such  entities. 
SENSOR-TYPE  is  a  subtype  of  MATERIEL-ITEM.  See  Figure 
A-4. 

•  TARGET 

•  CANDIDATE- 
TARGET 

•  FEATURE 

reportContactsO 

A  MILITARY-UNIT  has  associated  feature  entities.  See 

Figure  A-2.  A  MILITARY-UNIT  also  has  associated  TARGET 
and  CANDIDATE-TARGET  entities.  See  FigureA-15. 

The  degree  of  Entity  level  alignment  of  the  Intel  elass  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (37%). 


A.i.3.i.Thecollect()  Method  (State  Level) 

The  following  ambiguities  in  the  deseription  of  the  collectO  method  limit  alignment  analy¬ 
sis: 


•  The  OMSC  does  not  speeify  how  the  organie  sensor  assets  of  a  unit  are  defined. 

•  Deteetion  ean  involve  more  than  turning  on  a  sensor.  The  sensor  might  be  direeted 
against  some  feature,  other  organization,  ete.  The  OMSC  does  not  define  how  seareh 
eapabilities  may  be  effeeted  other  than  turning  them  on. 

•  The  OMSC  has  no  method  to  terminate  loeal  deteetion. 

There  is  no  State  level  alignment  (0%)  between  the  AICDM  and  the  OMSC  with  respeet 
to  the  collectO  method.  Nothing  about  how  the  collectO  method  aligns  to  the  AICDM  ean  be 
determined  at  the  State  level. 
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A.i.3.2.The  reportContactsO  Method  (State  Level) 


The  following  ambiguities  in  the  deseription  of  the  reportContactsO  method  limit  alignment 
analysis: 

•  The  OMSC  does  not  speeify  the  nature  of  results,  nor  how  they  might  be  used.  The 
only  other  method  assoeiated  with  a  Unit  that  might  use  intelligenee  is  C2.doC2(). 

There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  with  respeet  to  the  reportContactsO  method.  The  OMSC  does  not  speeify  the  nature 
of  the  method’s  results,  but  it  is  likely  that  a  eontaet  ean  be  modeled  either  as  a  TARGET  or 
a  FEATURE.  In  partieular,  the  AICDM  defines  a  FEATURE  as  “of  military  signifioanee.” 
However,  the  ambiguities  in  the  method’s  deseription  preelude  perfeet  alignment. 


Currently,  the  AICDM  laeks  domain  values  to  assoeiate  organizations  as  eontaets.  If  addi¬ 
tional  domain  values  for  the  role  eodes  in  the  assoeiative  entities  related  to  ORGANIZATION 
are  made  part  of  future  versions  of  the  AICDM  (e.g.,  “eontaeted  by”),  then 
ORGANIZATION-ASSOCIATION,  ORGANIZATION-MATERIEL,  ORGANIZATION-PERSON,  ete.,  eould 
be  used  to  eapture  this  OMSC  requirement. 


Value 


A.1.4.  Communications  Class  (Entity  Level) 

The  OMSC  Communications  elass  aligns  with  the  AICDM  TELECOMMUNICATIONS  NETWORK 
ELEMENT  entity.  This  entity  is  the  basis  of  an  element  of  a  teleoommunieations  network. 
TELECOMMUNICATIONS  NETWORK  ELEMENT  allows  many-to-many  assoeiations  between  its 
instanees,  via  the  TELECOMMUNICATIONS  NETWORK  ELEMENT  ASSOCIATION  entity.  This  as- 
soeiation  would  model  inter-organization  eommunieations. 

The  AICDM  models  eommunieations  equipment,  but  not  the  aet  of  eommunioating  (i.e., 
sending  messages).  The  AICDM  therefore  does  not  align  with  some  methods  of  the 
Communications  elass. 

Table  A-6  lists  the  AICDM  entities  that  align  with  the  Communications  elass  at  the  state 
level. 


Table  A-6.  AICDM  entities  that  align  with  the  Communications  class  at  the  Entity 

level 


AICDM  Entity 

Suggested  By 
OMSC  Method 

Relation  to  MILITARY-UNIT 

TELECOMMUNICATIONS- 

NETWORK-ELEMENT 

•  getNetO 

•  setNetO 

A  MILITARY-UNIT  has  associated 
TELECOMMUNICATIONS-NETWORK-ELEMENT  enti¬ 
ties.  See  Figure  A-6. 

TELECOMMUNICATIONS- 

NETWORK-ELEMENT-LINK- 

RADIO 

•  getNetO 

•  setNetO 

TELECOMMUNICATIONS-NETWORK-ELEMENT-LINK- 
RADIO  isa  subtypeofTELECOMMUNICATIONS- 
NETWORK-ELEMENT.  SeeFigureA-6. 
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AICDM  Entity 

Suggested  By 
OMSC  Method 

Relation  to  MILITARY-UNIT 

TELECOMMUNICATIONS- 

NETWORK-ELEMENT- 

ASSOCIATION 

•  getNetO 

•  setNetO 

ATELECOMMUNICATIONS-NETWORK-ELEMENT- 
ASSOCIATION  forms  a  network  of 
TELECOMMUNICATIONS-NETWORK-ELEMENT  enti¬ 
ties.  See  Figure  A-6. 

INFORMATION-REFERENCE 

•  sendMessageO 

•  receiveMessageO 

An  INFORMATION-REFERENCE  models  a  message. 
SeeFigureA-16. 

The  degree  of  Entity  level  alignment  of  the  Communications  elass  is  the  average  of  the  de¬ 
grees  of  alignment  of  its  methods  (81%). 


A.i.4.i.The  getNetO  Method  (State  Level) 

The  following  ambiguities  in  the  deseription  of  the  getNetO  method  limit  alignment  analy¬ 
sis: 

•  The  OMSC  does  not  speeify  the  types  of  objeets  that  might  be  modeled  in  a  eommu- 
nieations  network. 

Presumably,  the  objeets  to  be  modeled  inelude  eomponents  of  the  unit  hierarehy. 
They  may  also  inelude  platforms. 

•  The  method’s  deseription  says  that  it  the  eolleetion  of  objeets  “eapable  of  exehanging 
messages.”  What  are  the  bounds  of  eapability?  Can  they  inelude  foes  as  well  as 
friends? 

This  analysis  assumes  that  eapability  is  defined  by  the  setNetO  method.  In  other  words, 
the  objeets  eapable  of  exehanging  messages  are  exaetly  those  added  by  setNetO,  be 
they  friend  or  foe. 

•  Is  the  intent  of  eommunieations  to  eapture  eleetronie  message  exehange?  Or  does  it 
inelude  other  types  of  signals  (e.g.,  semaphores,  written  eommunieation,  or  for  that 
matter  verbal  eommunieation)? 

This  analysis  assumes  that  eommunieations  model  messages  sent  over  an  eleetronie 
network. 

There  is  perfect  State  level  alignment  (100%)  between  the  AICDM  and  the  OMSC  with 
respeet  to  the  getNetO  method.  The  result  of  the  getNetO  method  should  be  equivalent  to  the 
set  of  TELECOMMUNICATIONS-NETWORK-ELEMENT  entities  in  the  network  modeled  by  the 
instanee  of  Communieations. 

A.i.4.2.The  setNetO  Method  (State  Level) 

The  ambiguities  of  the  getNetO  method  (see  Seetion  A.1.4.1)  apply  to  the  setNetO  method. 
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This  is  a  behavioral  method.  Its  deseription  states  that  its  effeet  is  to  “add  the  unit  to  the 
eolleetion  of  objeets  eapable  of  exehanging  messages.”  This  seems  to  imply  that  eaeh 
simulation  has  a  single  network.  If  so  then  the  AICDM,  whieh  ean  model  multiple  eom- 
munieations  networks,  is  more  powerful  than  the  OMSC. 

There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  with  respeet  to  the  setNetO  method.  The  result  of  invoking  the  setNetO  method  is 
that  the  unit  should  appear  in  the  eolleetion  of  objeets  returned  by  getNet().  However, 
setNetO  eannot  be  used  to  model  eommunieations  networks.  It  adds  a  unit  to  a  eommuni- 
eations  network,  but  does  not  provide  for  defining  network  topology.  AICDM  relation¬ 
ships  among  entities  define  network  topology  (the  TELECOMMUNICATIONS-NETWORK- 
ELEMENT-ASSOCIATION  entity  eaptures  this  information).  In  the  absenee  of  topologieal  in¬ 
formation,  the  OMSC  appears  eapable  of  modeling  only  one  network.  In  other  words,  the 
OMSC’s  model  of  eommunieations  is  weaker  than  the  AICDM’s. 

A.i.4.3.ThesendMessage()  Method  (State  Level) 

This  is  a  behavioral  method.  It  sends  a  message  on  a  net. 

There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  with  respeet  to  the  sendMessageO  method.  The  result  of  invoking  the  method  ean 
be  modeled  by: 

•  The  assoeiation  of  an  INFORMATION-REFERENCE  entity  to  an  ORGANIZATION  entity.  The 
attributes  of  INFORMATION-REFERENCE  reeord  the  time  at  whieh  the  message  is  sent 
(see  Figure  A-16). 

•  The  assoeiation  of  an  ACTION-OBJ  ECTIVE-ITEM  (speeifying  the  PERSON,  ORGANIZATION, 
or  FEATURE  that  is  to  reeeive  the  message)  to  the  ORGANIZATION  that  sends  the  mes¬ 
sage  (see  Figure  A- 15). 

However: 

•  If  an  organization  possesses  multiple  teleeommunieations  network,  it  is  not  elear  that 
the  AICDM  ean  model  the  assoeiation  of  a  message  being  sent  on  a  partieular  net¬ 
work. 

•  The  attribute  values  for  AICDM  aetions  (from  the  ACTION -VERB  CODE  attribute)  do  not 
inelude  values  for  sending  messages. 

For  these  reasons,  the  alignment  is  not  perfeet. 
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ORGANIZATION 


ORGANIZATION  IDENTIFIER 


IDENTIFICATION-FRIEND-FOE  CODE  (FK) 
Principal  EQUIPMENT-TYPE  Code 
ORGANIZATION  CATEGORY  CODE 
ORGANIZATION  CLASSIFICATION  CODE 
ORGANIZATION  DESCRIPTION  TEXT 
ORGANIZATION  DURATION  TYPE  CODE 
ORGANIZATION  PRIMARY  ACTIVITY  CODE 
ORGANIZATION  TYPE  CODE 


applies  to 


IDENTIFICATION-FRIEND-FOE 
-A  IDENTIFICATION-FRIEND-FOE  CODE 


ORGANIZATION-INFORMATION-REFERENCE 


referenced  to 


ORGANIZATION  IDENTIFIER  (FK) 

ORGANIZATION-INFORMATION-REFERENCE  IDENTIFIER 
INFORMATION-REFERENCE  IDENTIFIER  (FK) 


ORGANIZATION-INFORMATION-REFERENCE  BEGIN  CALENDAR  DATE-TIME 
ORGANIZATION-INFORMATION-REFERENCE  END  CALENDAR  DATE-TIME 
ORGANIZATION-INFORMATION-REFERENCE  ROLE  CODE 


FACILITY-INFORMATION-REFERENCE 


FACILITY  IDENTIFIER 

FACILITY-INFORMATION-REFERENCE  IDENTIFIER 
INFORMATION-REFERENCE  IDENTIFIER  (FK) 

FACILITY-INFORMATION-REFERENCE  BEGIN  CALENDAR  DATE-TIME 
FACILITY-INFORMATION-REFERENCE  END  CALENDAR  DATE-TIME 
FACILITY-INFORMATION-REFERENCE  ROLE  CODE 


provides  relevant  information  for 


provides  relevant  information  for 


ACTION-INFORMATION-REFERENCEw 


ACTION  IDENTIFIER 

ACTION-INFORMATION-REFERENCE  IDENTIFIER 
INFORMATION-REFERENCE  IDENTIFIER  (FK) 

ACTION-INFORMATION-REFERENCE  BEGIN  CALENDAR  DATE-TIME 
ACTION-INFORMATION-REFERENCE  END  CALENDAR  DATE-TIME 
ACTION-INFORMATION-REFERENCE  ROLE  CODE 


GUIDANCE-INFORMATION-REFERENCE 


GUIDANCE  IDENTIFIER 
INFORMATION-REFERENCE  IDENTIFIER  (FK) 
GUIDANCE-INFORMATION-REFERENCE  IDENTIFIER 


GUIDANCE-INFORMATION-REFERENCE  BEGIN  CALENDAR  DATE-TIME 
GUIDANCE-INFORMATION-REFERENCE  END  CALENDAR  DATE-TIME 
GUIDANCE-INFORMATION-REFERENCE  ROLE  CODE 


provides  relevant  information  for 


provides  relevant  information  for 


INFORMATION-REFERENCE 


provides  relevant  information  for 


PERSON-INFORMATION-REFERENCE 


PERSON  IDENTIFIER 

INFORMATION-REFERENCE  IDENTIFIER  (FK) 
PERSON-INFORMATION-REFERENCE  IDENTIFIER 

PERSON-INFORMATION-REFERENCE  BEGIN  CALENDAR  DATE-TIME 
PERSON-INFORMATION-REFERENCE  END  CALENDAR  DATE-TIME 
PERSON-INFORMATION-REFERENCE  ROLE  CODE 


INFORMATION-REFERENCE  IDENTIFIER 

INFORMATION-REFERENCE  ALTERNATE  IDENTIFIER 
INFORMATION-REFERENCE  CATEGORY  CODE 
INFORMATION-REFERENCE  DESCRIPTION  TEXT 
INFORMATION-REFERENCE  EFFECTIVE  CALENDAR  DATE-TIME 
INFORMATION-REFERENCE  FILE  NAME 
INFORMATION-REFERENCE  FORMAT  CODE 
INFORMATION-REFERENCE  NAME 
INFORMATION-REFERENCE  REMARK  TEXT 


provides  relevant  information  for 


provides  relevant  information  for 


MATERIEL-INFORMATION-REFERENCE 


MATERIEL  IDENTIFIER 

MATERIEL-INFORMATION-REFERENCE  IDENTIFIER 
INFORMATION-REFERENCE  IDENTIFIER  (FK) 

MATERIEL-INFORMATION-REFERENCE  ROLE  CODE 
MATERIEL-INFORMATION-REFERENCE  BEGIN  CALENDAR  DATE-TIME 
MATERIEL-INFORMATION-REFERENCE  END  CALENDAR  DATE-TIME 


FEATURE-INFORMATION-REFERENCE 
^FEATURE  IDENTIFIER 

FEATURE-INFORMATION-REFERENCE  IDENTIFIER 
INFORMATION-REFERENCE  IDENTIFIER  (FK) 

FEATURE-INFORMATION-REFERENCE  BEGIN  CALENDAR  DATE-TIME 
FEATURE-INFORMATION-REFERENCE  END  CALENDAR  DATE-TIME 
FEATURE-INFORMATION-REFERENCE  ROLE  CODE 


Figure  A-16.  AlCDM  Structures  for  Information  Reference 

A.i.4.4.The  receiveMessageO  Method  (State  Level) 

This  is  a  behavioral  method.  It  reeeives  a  message  on  a  net. 


There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  with  respeet  to  the  receiveMessageO  method.  The  result  of  invoking  the  method  ean 
be  modeled  by: 
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•  The  association  of  an  INFORMATION-REFERENCE  entity  to  an  ORGANIZATION  entity.  The 
attributes  of  INFORMATION-REFERENCE  record  the  time  at  which  the  message  is  re¬ 
ceived  (see  Figure  A-16). 

•  The  association  of  an  ACTION-OBJ  ECTIVE-ITEM  (specifying  the  PERSON,  ORGANIZATION, 
or  FEATURE  that  sent  the  message)  to  the  ORGANIZATION  that  receives  the  message  (see 
Figure  A-15). 

However; 

•  If  an  organization  possesses  multiple  telecommunications  network,  it  is  not  clear  that 
the  AICDM  can  model  the  association  of  a  message  being  received  on  a  particular 
network. 

•  The  attribute  values  for  AICDM  actions  (from  the  ACTION -VERB  CODE  attribute)  do  not 
include  values  for  sending  messages. 

For  these  reasons,  the  alignment  is  not  perfect. 

There  is  some  overlap  between  the  model  elements  proposed  here  and  for  the 
sendMessageO  method  in  Section  A.  1.4. 3.  A  data  model  may  not  need  to  record  all  the 
elements. 

A.1.5.  SystemGroup  Class  (Entity  Level) 

The  SystemGroup  class  models  systems  within  a  unit.  The  descriptions  of  the  methods  as¬ 
sociated  with  the  class  only  mention  types  of  systems,  rather  than  individual  systems. 
Therefore,  the  analysis  aligns  SystemGroup  only  to  those  AICDM  entities  that  model  types 
of  systems,  not  individual  systems.  If  for  some  reason  SystemGroup  must  be  aligned  to  in¬ 
dividual  systems.  Table  A-7  will  need  to  include  the  MATERIEL  entity. 


Table  A-7.  AICDM  entities  that  align  with  the  SystemGroup  class  at  the  State  level 


AICDM  Entity 

Suggested  By  OMSC 
Method 

Relation  to  MILITARY-UNIT 

MATERIEL-ITEM  and 
its  subtypes 

•  getQtyO 

•  acceptLossesO 

•  acceptGainsO 

The  MATERIEL-ITEM  entity 
models  the  type  of  system; 
the  MATERIEL-ITEM-HOLDING- 
ESTIMATE  entity  models  the 
quantity. 

A  MILITARY-UNIT  has  associated  MATERIEL- 
ITEM  entities.  See  Figure  A-4. 

MATERIEL-ITEM- 

HOLDING-ESTIMATE 

A  MILITARY-UNIT  is  inventoried  by 
MATERIEL-ITEM-ORGANIZATION-HOLDING- 
ESTIMATE.  See  Figure  A-13. 

The  degree  of  Entity  level  alignment  of  the  SystemGroup  class  is  the  average  of  the  degrees 
of  alignment  of  its  methods  (100%). 
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A.i.5.i.The  getQtyO  Method  (State  Level) 

There  is  perfect  State  level  alignment  (100%)  between  the  AICDM  and  the  OMSC  with 
respeet  to  the  getQtyO  method.  The  result  of  getQtyOmaps  to  the  value  of  the  MATERIEL-ITEM- 
ORGANIZATION-HOLDING-ESTIMATE  QUANTITY  attribute.  See  Figure  A-13. 

A.i.5.2.TheacceptLosses()  and  acceptGainsO  Methods 
(State  Level) 

These  are  behavioral  methods.  Aeeepting  losses  (gains)  means  removing  (adding) 
MATERIEL-ITEM  entities. 

There  is  perfect  State  level  alignment  (100%)  between  the  AICDM  and  the  OMSC  with 
respeet  to  these  methods.  The  removal  (addition)  of  a  MATERIEL-ITEM  entity  implies  the 
need  to  invoke  the  acceptLossesO  (acceptGainsO)  method.  The  amount  of  losses  (gains)  is 
determined  by  the  relation  of  the  entity  to  a  MATERIEL-ITEM-ORGANIZATION-HOLDING 
ESTIMATE  entity:  the  losses  (gains)  equal  the  value  of  the  MATERIEL-ITEM-ORGANIZATION- 
HOLDING-ESTIMATE  QUANTITY  attribute. 

A.1.6.  Platform  Class  (Entity  Level) 

In  the  speeifieation  of  the  Unit  standard  objeet,  the  Platform  elass  has  no  methods.  Pre¬ 
sumably  it  is  a  plaeeholder  for  the  Platform  standard  objeet,  whose  degree  of  alignment  is 
48%.  See  Seetion  A.2. 

A.1.7.  PlatformI nfo  Class  (Entity  Level) 

In  the  speeifieation  of  the  Unit  standard  objeet,  the  Platforminfo  elass  has  no  methods.  The 
elass’  deseription  states  that  it  provides  information  about  a  platform’s  physieal  eharaeter- 
isties. 

The  Platform  standard  objeet  has  a  elass  named  PlatformFrame.  This  elass’  getSIgnatureO 
method  provides  physieal  eharaeteristies.  However,  the  deseriptions  for  PlatformFrame  im¬ 
ply  that  its  foeus  is  narrower  than  that  of  Platforminfo.  PlatformFrame  primarily  provides  data 
used  by  sensors.  Platforminfo  does  not  eontain  this  restrietion. 

There  is  a  low  degree  of  Entity  level  alignment  (25%)  between  the  AICDM  and  the 
OMSC  with  respeet  to  the  Platforminfo  elass.  The  AICDM  has  a  limited  set  of  entities  with 
attributes  that  ean  model  physieal  eharaeteristies  (see  Figure  A- 17): 
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MATERIEL-ITEM  IDENTIFIER 


MATERIEL-ITEM  COMMODITY  TYPE  CODE 
MATERIEL-ITEM  CONTROL  NUMBER  TYPE  CODE 
MATERIEL-ITEM  CRITICAL  APPLICATION  CODE 
MATERIEL-ITEM  DEMILITARIZATION  CODE 
MATERIEL-ITEM  DESCRIPTION  TEXT 
MATERIEL-ITEM  END  INDICATOR  CODE 
MATERIEL-ITEM  ESSENTIALITY  CODE 
MATERIEL-ITEM  FEDERAL  SUPPLY  SCHEDULE  IDENTIFIER 
MATERIEL-ITEM  FIRST  ARTICLE  TEST  CODE 
MATERIEL-ITEM  FOREIGN  PRODUCED  INDICATOR  CODE 
MATERIEL-ITEM  FREIGHT  INTEGRITY  CODE 
MATERIEL-ITEM  HIGH  DOLLAR  CODE 
MATERIEL-ITEM  NAME 

MATERIEL-ITEM  NET  CONTRACT  DUEIN  UNIT  QUANTITY 
MATERIEL-ITEM  NET  PURCHASE  ORDER  DUEIN  UNIT  QUANTITY 
MATERIEL-ITEM  PACKAGING  DATA  AVAILABILITY  CODE 
MATERIEL-ITEM  PREFERRED  INSPECTION  PLACE  CODE 
MATERIEL-ITEM  PREFERRED  INSPECTION  TYPE  CODE 
MATERIEL-ITEM  PRODUCTION  INDICATOR  CODE 
MATERIEL-ITEM  PRODUCTION  LEADTIME  DAYS  QUANTITY 
MATERIEL-ITEM  PROMPT  PAY  DAY  QUANTITY 
MATERIEL-ITEM  PURCHASE  DESCRIPTION  TEXT 
MATERIEL-ITEM  REFERENCE  NUMBER  IDENTIFIER 
MATERIEL-ITEM  SELECTIVELY  MANAGED  CODE 
MATERIEL-ITEM  SHELF  LIFE  QUANTITY 
MATERIEL-ITEM  SPECIAL  ACTION  IDENTIFIER 
MATERIEL-ITEM  STORAGE  REQUIREMENT  TEXT 
MATERIEL-ITEM  TYPE  CODE 


EQUIPMENT-TYPE 


MATERIEL-ITEM  IDENTIFIER  (FK) 


EQUIPMENT-TYPE  Alternate  Identifier 
EQUIPMENT-TYPE  CARGO  AREA 
EQUIPMENT-TYPE  CARGO  DESCRIPTION  TEXT 
EQUIPMENT-TYPE  CARGO  HEIGHT  DIMENSION 
EQUIPMENT-TYPE  CARGO  LENGTH  DIMENSION 
EQUIPMENT-TYPE  CARGO  VOLUME 
EQUIPMENT-TYPE  CARGO  WEIGHT 
EQUIPMENT-TYPE  CARGO  WIDTH  DIMENSION 
EQUIPMENT-TYPE  Category  Code 
EQUIPMENT-TYPE  MODEL  SERIES  IDENTIFIER 
EQUIPMENT-TYPE  Popular  Name 


y 


VEHICLE-TYPE 


I  VEHICLE-TYPE  CODE 


MATERIEL-ITEM  IDENTIFIER  (FK) 

VEHICLE-TYPE  FORDING  CAPABILITY  DIMENSION 
VEHICLE-TYPE  HEIGHT  DIMENSION 
VEHICLE-TYPE  LENGTH  DIMENSION 
VEHICLE-TYPE  NAME 

VEHICLE-TYPE  SUSTAINED  SPEED  MAXIMUM  RATE 
VEHICLE-TYPE  WIDTH  DIMENSION 


may  be  a 


T 


MATERIEL-ASSOCIATION 


is  the  subject  of 


is  the  class  for 


MATERIEL-ASSOCIATION  IDENTIFIER 
ORDINATE  MATERIEL  IDENTIFIER  (FK) 
SUBORDINATE  MATERIEL  IDENTIFIER  (FK) 

MATERIEL-ASSOCIATION  TYPE  CODE 


MATERIEL 

is  the  object  of 

i 

MATERIEL  IDENTIFIER 

MATERIEL-ITEM  IDENTIFIER  (FK) 

MATERIEL-SERIALIZED-ITEM  CONTROL  NUMBER  IDENTIFIER 

MATERIEL  ALTERNATE  IDENTIFIER 

MATERIEL  CATEGORY  CODE 

MATERIEL  FRIEND  FOE  CODE 

MATERIEL  Lot  Identification  Text 

participates  in 

participates  in 

MATERIEL-ORGANIZATION 


i 


MATERIEL-ORGANIZATION  IDENTIFIER 
ORGANIZATION  IDENTIFIER 
MATERIEL  IDENTIFIER  (FK) 

MATERIEL-ORGANIZATION  TYPE  CODE 


MATERIEL-PERSON 


MATERIEL-PERSON  IDENTIFIER 
MATERIEL  IDENTIFIER  (FK) 
PERSON  IDENTIFIER 


MATERIEL-PERSON  TYPE  CODE 


Figure  A-17.  AlCDM  Structures  That  May  Support  Platform  Specifications 

•  Section  A.2. 1 1  discusses  platform  signatures. 

•  The  AICDM  can  model  weights  and  sizes  of  some  types  of  equipment: 

-  The  EQUIPMENT-TYPE  entity  has  height,  length,  width,  volume,  and  weight  at¬ 
tributes. 

-  The  VEHICLE-TYPE  entity  has  height,  length,  and  width  attributes.^ 


^  The  DDA  has  other  attributes  that  also  keep  track  of  weight,  length,  etc.,  which  are  not  in  the  AICDM. 
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A.1.8.  Attrition  Ciass  (Entity  Levei) 


The  Attrition  class  does  not  model  object  instances  but  rather  encapsulates  algorithms  for 
causing  attrition.  The  AICDM  entities  that  align  with  attrition  are  shown  in  Table  A-8. 


Table  A-8.  AlC DM  Entities  that  align  with  the  Attrition  class  at  the  Entity  level 


AICDM  Entity 

Suggested  By 
OMSC  Method 

Relation  to  MILITARY-UNIT 

•  MATERIEL-ITEM 

•  PERSON-TYPE 

•  *-0RGANIZATI0N- 
HOLDING-ESTIMATE 

causeAttritionO 

A  MILITARY-UNIT  has  associated  MATERIEL-ITEM 
entities.  The  association  (HOLDING  entities)  re¬ 
cords  the  number  of  entities.  See  Figure  A-13. 

•  PERSON 

•  PERSON-OPERATIONAL- 
STATUS 

causeAttritionO 

A  MILITARY-UNIT  has  associated  PERSON  entities. 

A  PERSON  has  an  associated  PERSON- 
OPERATIONAL-STATUS.  See  Figure  A-4. 

•  MATERIEL 

•  MATERIEL- 
OPERATIONAL-STATUS 

causeAttritionO 

A  MILITARY-UNIT  has  associated  MATERIEL  enti¬ 
ties.  MATERIEL  has  an  associated  MATERIEL- 
OPERATIONAL-STATUS.  See  Figure  A-7. 

The  degree  of  Entity  level  alignment  of  the  Attrition  class  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (75%). 


A.i.8.i.ThecauseAttrition()  Method  (State  Level) 

The  following  ambiguities  in  the  description  of  the  causeAttritionO  method  limit  alignment 
analysis: 

•  The  OMSC  does  not  specify  how  the  type  of  attrition  is  determined,  nor  how  the 
amount  of  attrition  is  determined.  Lacking  this  information,  the  analysis  is  necessarily 
vague  about  the  details  of  attrition. 

Furthermore,  none  of  the  OMSC  classes  have  any  methods  to  specify  losses.  The  intent  is 
probably  that  losses  be  modeled  by  deleting  associations.  For  example,  the  loss  of  a  plat¬ 
form  would  be  modeled  by  removing  an  existing  association  between  a  unit  and  a  plat¬ 
form. 

This  is  a  behavioral  method.  It  causes  attrition  to  another  unit.  We  can  infer  the  follow¬ 
ing: 


•  The  description  of  the  class  states  that  attrition  is  caused  by  means  such  as  direct  fire 
systems.  Therefore,  causing  attrition  requires  depleting  materiel. 

There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  causeAttritionO  method.  The  change  in  state  caused  by 
determineAttritionO  will  be  losses  of  personnel,  materiel,  etc.  from  both  the  unit  causing  attri¬ 
tion  and  the  unit  receiving  the  damage.  How  an  M&S  system  effects  this  depends  on 
whether  the  system  models  individual  entities  or  quantity  of  entities;  e.g.,  whether  it  re¬ 
cords  that  a  unit  has  tanks  identified  A,  B,  and  C  or  simply  notes  that  a  unit  has  3  tanks.  If 
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it  models  individual  entities,  then  the  ehange  in  state  aligns  to  the  following  AICDM  at¬ 
tributes  (see  Figure  A- 18): 

•  PERSON-ORGANIZATION  BEGIN  CALENDAR  DATE-TIME 

•  PERSON-ORGANIZATION  END  CALENDAR  DATE-TIME 

•  MATERIEL-ORGANIZATION  (N.B.  this  is  an  entity,  and  it  laeks  a  date-time  attribute  to 
reeord  when  the  assoeiation  exists.) 

•  PERSON-OPERATIONAL-STATUS  CODE 

•  MATERIEL-OPERATIONAL-STATUS  CODE 

If  the  system  models  entity  quantity,  the  ehange  in  state  aligns  to  the  following  AICDM 
attributes: 

•  PERSON-TYPE-ORGANIZATION-HOLDING-ESTIMATE  OUANTITY, 
PERSON-TYPE-ORGANIZATION-HOLDING-ESTIMATE  CALENDAR  DATE-TIME 

•  MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE  OUANTITY, 
MATERIEL-ITEM-ORGANIZATION-HOLDING-ESTIMATE  CALENDAR  DATE-TIME 

However,  the  AICDM  ean  model  only  limited  kinds  of  attrition  if  the  simulation  uses  FvXlue 
entity  quantity.  The  HOLDING  entities  have  a  STATUS  CODE  attribute  that  ean  reeord  the 
state  of  a  materiel  item  or  person,  but  this  attribute  has  a  limited  range  of  values.  Essen¬ 
tially,  the  AICDM  ean  model  that  a  group  of  materiel  items  or  people  are  in  or  out  of  no¬ 
tion.  It  oannot  reeord  nuanoes  of  attrition,  suoh  as  indioating  that  a  tank  is  mobile  but 
oannot  use  its  weaponry. 


A-35 


ORGANIZATION 


participates  in 


MATERIEL-ORGANIZATION 
^MATERIEL-ORGANIZATION  IDENTIFIER 
ORGANIZATION  IDENTIFIER  (FK) 
MATERIEL  IDENTIFIER 

MATERIEL-ORGANIZATION  TYPE  CODE 


ORGANIZATION  IDENTIFIER 


IDENTIFICATION-FRIEND-FOE  CODE 
Principal  EQUIPMENT-TYPE  Code 
ORGANIZATION  CATEGORY  CODE 
ORGANIZATION  CLASSIFICATION  CODE 
ORGANIZATION  DESCRIPTION  TEXT 
ORGANIZATION  DURATION  TYPE  CODE 
ORGANIZATION  PRIMARY  ACTIVITY  CODE 
ORGANIZATION  TYPE  CODE 


participates  in 


ORGANIZATION-FEATURE 


ORGANIZATION-FEATURE  IDENTIFIER 
ORGANIZATION  IDENTIFIER  (FK) 
FEATURE  IDENTIFIER 


ORGANIZATION-FEATURE  ROLE  CODE 
ORGANIZATION-FEATURE  BEGIN  CALENDAR  DATE-TIME 
ORGANIZATION-FEATURE  END  CALENDAR  DATE-TIME 


is  referenced  by 


relates  to 


ORGANIZATION-FACILITY 


FACILITY  IDENTIFIER 
ORGANIZATION  IDENTIFIER  (FK) 
ORGANIZATION-FACILITY  IDENTIFIER 


ORGANIZATION-FACILITY  EFFECTIVE  BEGIN  CALENDAR  DATE-TIME 
ORGANIZATION-FACILITY  EFFECTIVE  END  CALENDAR  DATE-TIME 
ORGANIZATION-FACILITY  ROLE  CODE 


is  the  subject  of 


is  the  object  of 

ORGANIZATION-ASSOCIATION 


ORDINATE  ORGANIZATION  IDENTIFIER  (FK) 

SUBORDINATE  ORGANIZATION  IDENTIFIER  (FK) 
ORGANIZATION-ASSOCIATION  IDENTIFIER 

ORGANIZATION-ASSOCIATION  CONFIGURATION  CATEGORY  CODE 
ORGANIZATION-ASSOCIATION  EFFECTIVE  CALENDAR  DATE-TIME 
ORGANIZATION-ASSOCIATION  END  CALENDAR  DATE-TIME 
ORGANIZATION-ASSOCIATION  REINFORCEMENT  CATEGORY  CODE 
ORGANIZATION-ASSOCIATION  TYPE  CODE 


PERSON-ORGANIZATION 


ORGANIZATION  IDENTIFIER  (FK) 

PERSON  IDENTIFIER 

PERSON-ORGANIZATION  BEGIN  CALENDAR  DATE-TIME 


PERSON-ORGANIZATION  PERSON  ROLE  CODE 
PERSON-ORGANIZATION  PROJECTED  END  CALENDAR  DATE-TIME 
PERSON-ORGANIZATION  END  CALENDAR  DATE-TIME 

V _ ✓ 


FigureA-18.  AlCDM  Associative  Entities  for  Organization 


A.1.9.  Logistics  Class  (Entity  Level) 

The  Logistics  class  represents  logistics  capability  of  a  unit.  Figure  A- 19  shows  the  struc¬ 
tures  for  specifying  Holdings  in  the  AICDM.  Table  A-9  shows  the  AICDM  entities  that 
align  with  OMSC  classes. 


Table  A-9.  AICDM  entities  that  align  with  the  Logistics  class  attheEntity  level 


AICDM  Entity 

Suggested 
By  OMSC 
Method 

Relation  to  MILITARY-UNIT 

•  PERSON-TYPE- 
ORGANIZATION-HOLDING- 
ESTIMATE 

•  MATERIEL-ITEM- 
ORGANIZATION-HOLDING- 
ESTIMATE 

receive!) 

A  M 1 L ITAR  Y-U  N  IT  has  associ  ated  M  AT  E  R 1 E  L-  IT  E  M 
and  PERSON-TYPE  entities.  The  association 
(HOLDING  entities)  records  the  number  of  enti¬ 
ties.  SeeFigureA-19. 
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AICDM  Entity 

Suggested 
By  OMSC 
Method 

Relation  to  MILITARY-UNIT 

•  MATERIEL 

•  PERSON 

•  MATERIEL-OPERATIONAL- 
STATUS 

•  PERSON-OPERATIONAL- 
STATUS 

received 

•  A  MILITARY-UNIT  has  associated  MATERIEL 
entities.  MATERIEL  has  an  associated  MATERIEL- 
OPTIONAL-STATUS.  See  Figure  A-7. 

•  A  MILITARY-UNIT  has  associated  PERSON 
entities.  A  PERSON  has  an  associated  PERSON- 
OPERATIONAL-STATUS.  See  Figure  A-4. 

The  Logistics  class  description  refers  to  types  of  logistics  components.  None  of  the  meth¬ 
ods  in  the  Logistics  class  specify  component  type,  so  Logistics  is  probably  an  abstract  class. 
Since  Maintenance  and  Suppiy  are  subclasses  of  Logistics,  the  OMSC  apparently  intends  to 
make  use  of  multiple  inheritance. 

The  degree  of  Entity  level  alignment  of  the  Logistics  class  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (75%). 

A.i.9.i.The  receiveO  Method  (State  Level) 

This  is  a  behavioral  method.  It  increments  the  quantity  of  a  logistics  component. 

There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  received  method.  As  with  attrition  (see  Section  ),  how  the  ef¬ 
fects  of  the  received  method  align  with  the  AICDM  depend  on  whether  the  M&S  system 
models  individual  logistics  components  or  simply  the  quantity  of  types  of  components.  If 
the  M&S  system  models  individual  logistics  components,  then  the  effect  of  the  method  is 
to  add  associations  between  a  Unit  instance  and  a  Logistics  instance.  In  that  case,  the  effect 
of  the  method  in  AICDM  terms  is  to  add  a  MATERIEL-ORGANIZATION  entity,  relating  to  the 
ORGANIZATION  modeling  the  unit  and  the  MATERIEL  modeling  the  logistics  component  via 
“participates  in”  relationships. 

If  the  M&S  system  models  only  quantity  of  logistics  components,  the  effect  of  received  in 
AICDM  terms  is  to  add  a  *-ORGANIZATION-HOLDING-ESTIMATE  entity,  relating  a  MATERIEL- 
ITEM  modeling  the  type  of  logistics  component  to  the  ORGANIZATION  receiving  it. 

The  AICDM  may  not  be  able  to  model  items  that  are  received  in  less  than  perfect  condi¬ 
tion.  See  Section  A. 2. 1.5. 
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Figure  A-19.  AlCDM  Structures  for  Specifying  Holdings 


A.1.10.  Maintenance  Class  (Entity  Level) 

The  MAINTENANCE  class  represents  the  maintenance  capability  of  a  unit.  The  entities  in 
Table  A-10  identify  the  AICDM  entities  that  align  with  the  M  aintenance  class: 


Table  A- 10.  AICDM  entities  that  align  with  the  Maintenance  class  at  the  Entity 

level 


AICDM  Entity 

Suggested  By  OMSC 
Method 

Relation  to  MILITARY-UNIT 

•  MATERIEL 

•  MATERIEL-OPERATIONAL- 
STATUS 

•  PERSON 

•  PERSON-OPERATIONAL- 
STATUS 

conductMaintenanceO 
(when  the  M  6(S  system 
is  modeling  individual 
persons  and  materiel 
items) 

•  A  MILITARY-UNIT  has  associated 
MATERIEL  entities.  MATERIEL  has 
an  associated  MATERIEL- 
OPTIONAL-STATUS.  See  Figure 

A-7. 

•  A  MILITARY-UNIT  has  associated 
PERSON  entities.  A  PERSON  has 
an  associated  PERSON- 
OPERATIONAL-STATUS.  See  Figure 
A-4. 
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AICDM  Entity 

Suggested  By  OMSC 
Method 

Relation  to  MILITARY-UNIT 

•  PERSON 

•  LOCATION 

•  PERSON-OPERATIONAL- 
STATUS 

•  conductRecoveryO 

•  conductEvacuationO 
(when  the  M  S(S  system 
is  modeling  individual 
persons) 

A  MILITARY-UNIT  has  associated 
PERSON  entities.  A  PERSON  has  a 
LOCATION.  SeeFigureA-4. 

•  MATERIEL 

•  LOCATION 

•  MATERIEL-OPERATIONAL- 
STATUS 

•  conductRecoveryO 

•  conductEvacuationO 
(when  the  M  S(S  system 
is  modeling  individual 
materiel  items) 

A  MILITARY-UNIT  has  associated 
MATERIEL.  MATERIEL  hasa  LOCA¬ 
TION,  identified  by  a  CONTROL- 
FEATURE.  See  Figure  A-7. 

•  PERSON-TYPE-ORGANIZATION- 
HOLDING-ESTIMATE 

•  MATERIEL-ITEM- 
ORGANIZATION-HOLDING- 
ESTIMATE 

conductEvacuationO  (when 
an  M&S  system  is 
modeling  number  of 
persons  or  materiel 
items) 

A  MILITARY-UNIT  has  associated 
MATERIEL-ITEM  and  PERSON-TYPE 
entities.  The  association  (HOLDING 
entities)  records  the  number  of 
entities.  SeeFigureA-4. 

The  degree  of  Entity  level  alignment  of  the  Maintenance  elass  is  the  average  of  the  degrees 
of  alignment  of  its  methods  (42%). 


A.i.io.i.TheconductMaintenance()  Method  (State  Level) 

The  following  ambiguities  in  the  conductMaintenanceO  method  limit  the  alignment  analysis: 

•  The  OMSC  does  not  speeify  how  maintenanee  aetions  or  medieal  treatment  are 
stated.  Presumably,  maintenanee  aetions  and  medieal  treatments  eonsume  resourees 
and  personnel. 

•  The  OMSC  does  not  speeify  resultant  states.  In  other  words,  the  effeets  of  mainte¬ 
nanee  are  not  deseribed. 


There  is  a  low  degree  of  State  level  alignment  (25%)  between  the  AICDM  and  the 
OMSC  with  respeet  to  the  conductMaintenanceO  method.  Whether  the  AICDM  ean  model 
the  result  of  the  method  at  all  depends  on  whether  maintenanee  is  eondueted  on  individ¬ 
ual  items  or  on  groups  of  items.  If  it  is  eondueted  on  individual  items,  then  the  *- 
OPERATiONAL-STATUS  entities  ean  be  used,  though  they  are  still  not  fully  adequate.  For 
example  (see  Figure  A-20): 


PERSON-OPERATiONAL-STATUS  has  an  attribute  PERSON-OPERATiONAL-STATUS  CODE 
that  eaptures  the  status  of  an  individual.  It  has  only  a  few  values  (e.g.,  “ineapaeitated, 
not  walking”  vs.  “ineapaeitated,  walking”).  These  values  may  or  may  not  suffiee  to 
eapture  the  possible  states  of  an  individual  that  the  Maintenanee  elass  expeets. 


WALUE 


MATERIEL-OPERATIONAL-STATUS  has  an  attribute  MATERIEL-OPERATIONAL-STATUS  CODE 
that  eaptures  the  status  of  equipment.  It  has  16  different  values.  These  values  may  or 
may  not  suffiee  to  eapture  the  possible  states  of  equipment  that  the  Maintenanee  elass 
expeets. 


WALUE 
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Figure  A-20.  AlCDM  Structures  for  Specifying  Operational  Status 
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If  maintenance  is  conducted  on  groups  of  items,  the  AICDM  cannot  model  maintenance. 
The  holding  entities  apply  to  an  entire  organization.  The  AICDM  can  record  a  status 
value  for  all  entities  of  a  particular  type,  but  cannot  (for  example)  directly  model  a  situa¬ 
tion  where  half  of  the  entities  held  require  maintenance.  Such  aggregate  status  for  a  group 
would  have  to  be  calculated  from  the  operational  status  of  the  individual  entities’  com¬ 
posing  a  group. 

A.i.io.2.TheconductRecovery()  Method  (State  Level) 

The  following  ambiguities  in  the  conductRecoveryO  method  limit  the  alignment  analysis: 

•  The  OMSC  does  not  specify  how  recovery  actions  are  stated.  Presumably,  recovery 
consumes  resources  and  personnel. 

This  is  a  behavioral  method.  Its  effect  is  to  move  personnel  and  equipment  from  the  im¬ 
mediate  battle  area  to  front  line  medical  and  repair  facilities. 

The  method’s  effects  can  be  broken  down  more  precisely  to  include: 

•  The  use  of  personnel  and  consumption  of  materiel  to  recover  the  wounded  personnel 
and  damaged  equipment. 

•  The  change  of  location  for  the  recovered  personnel  and  the  damaged  equipment. 

Because  the  changes  in  location  are  still  within  the  front  lines,  we  assume  that  invoking 
method  does  not  change  the  unit’s  geometry.  (It  will  change  the  unit’s  location,  if  location 
is  computed  as  center  of  mass.) 

There  is  a  medium  degree  of  State  level  alignment  (50%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  conductRecoveryO  method.  Whether  the  effects  of  the  method  can 
be  modeled  in  the  AICDM  depends  on  whether  the  M&S  system  models  individual  per¬ 
sonnel  and  materiel  or  quantities  of  personnel  and  materiel.  If  the  system  models  individ¬ 
ual  personnel  and  materiel,  then  the  AICDM  can  model  changes  caused  by  the  method 
quite  well.  Invoking  the  method  corresponds  to  the  following  changes  to  an  AICDM 
model: 

•  Creating  new  PERSON-LOCATION  and  MATERIEL-LOCATION  entities  that  model  the  new 
locations,  and  associating  them  with  the  moved  personnel  and  materiel. 

•  Decrementing  the  supplies  needed  to  support  the  recovery  operation  (see  Sec¬ 
tion  A.  1.9). 

•  Changing  the  following  attributes  of  the  respective  *-0PERATI0NAL-STATUS  entities: 

-  *-C0DE,  which  describes  the  condition  of  a  person  or  materiel  (ready  vs.  out  of 
action,  e.g.). 
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Value 


-  ^-PROTECTION  LEVEL  CODE,  which  describes  level  of  vulnerability  of  a  person 
or  materiel.  (ABOVE  GROUND  and  BUNKERED  for  materiel). 

If  the  M&S  system  models  quantities,  then  the  AICDM  cannot  model  the  effect  of  the 
method.  The  AICDM  cannot  record  a  new  location  for  a  quantity  of  materiel  or  persons. 

A.i.io.3.TheconductEvacuation()  Method  (State  Level) 

The  following  ambiguities  in  the  conductEvacuationO  method  limit  the  alignment  analysis: 

•  The  OMSC  does  not  specify  how  evacuation  actions  are  stated.  Presumably,  evacua¬ 
tion  consumes  resources  and  personnel. 

This  is  a  behavioral  method.  Its  effect  is  to  move  personnel  and  equipment  to  rear  areas. 
The  method’s  effects  can  be  broken  down  more  precisely  to  include: 

•  The  use  of  personnel  and  consumption  of  materiel  to  evacuate  the  wounded  personnel 
and  damaged  equipment. 

•  The  change  of  location  for  the  evacuated  personnel  and  the  damaged  equipment. 

There  is  a  medium  degree  of  State  level  alignment  (50%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  conductEvacuationO  method.  Whether  the  effects  of  the  method 
can  be  modeled  in  the  AICDM  depends  on  whether  the  M&S  system  models  individual 
personnel  and  materiel  or  quantities  of  personnel  and  materiel.  If  the  system  models  indi¬ 
vidual  personnel  and  materiel,  then  the  AICDM  can  model  the  method’s  effects  quite  well 
(see  Figure  A-21).  Invoking  the  method  corresponds  to  the  following  changes  to  an 
AICDM  model: 
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LOCATION 


LOCATION  IDENTIFIER 


LOCATION  CATEGORY  CODE 
LOCATION  NAME 


locates 

1 


ORGANIZATION _ 

ORGANIZATION  IDENTIFIER 


IDENTIFICATION-FRIEND-FOE  CODE 
Principal  EQUIPMENT-TYPE  Code 
ORGANIZATION  CATEGORY  CODE 
ORGANIZATION  CLASSIFICATION  CODE 
ORGANIZATION  DESCRIPTION  TEXT 
ORGANIZATION  DURATION  TYPE  CODE 
ORGANIZATION  PRIMARY  ACTIVITY  CODE 
ORGANIZATION  TYPE  CODE 


occupies  locates 


ORGANIZATION-LOCATION _ 

"organization-location  IDENTIFIER  ' 

LOCATION  IDENTIFIER  (FK) 

ORGANIZATION  IDENTIFIER  (FK) 

ORGANIZATION-LOCATION  ASSOCIATION  CODE 
ORGANIZATION-LOCATION  DURATION  QUANTITY 
ORGANIZATION-LOCATION  EFFECTIVE  CALENDAR  DATE 
ORGANIZATION-LOCATION  EFFECTIVE  TIME 
ORGANIZATION-LOCATION  REASON  TEXT 
ORGANIZATION-LOCATION  SEQUENCE  IDENTIFIER 
' - ^ j 


FACILITY-LOCATION 


FACILITY-LOCATION  IDENTIFIER 

s 

LOCATION  IDENTIFIER  (FK) 

FACILITY  IDENTIFIER 

FACILITY-LOCATION  ASSOCIATION  CODE 
FACILITY-LOCATION  EFFECTIVE  CALENDAR!  DATE 
FACILITY-LOCATION  EFFECTIVE  TIME 
FACILITY-LOCATION  DURATION  QUANTITY 
FACILITY-LOCATION  SEQUENCE  IDENTIFIER 


PERSON-LOCATION 


'  LOCATION  IDENTIFIER  (FK)  ^ 

PERSON  IDENTIFIER 

PERSON-LOCATION  IDENTIFIER 

PERSON-LOCATION  ASSOCIATION  CODE 
PERSON-LOCATION  DURATION  QUANTITY 
PERSON-LOCATION  EFFECTIVE  CALENDAR  DATE 
PERSON-LOCATION  EFFECTIVE  TIME 
PERSON-LOCATION  REASON  TEXT 

PERSON-LOCATION  SEQUENCE  IDENTIFIER 

MATERIEL-LOCATION 

'  MATERIEL-LOCATION  IDENTIFIER 

LOCATION  IDENTIFIER  (FK) 

MATERIEL  IDENTIFIER 

MATERIEL-LOCATION  ASSOCIATION  CODE 
MATERIEL-LOCATION  DURATION  QUANTITY 
MATERIEL-LOCATION  EFFECTIVE  CALENDAR  DATE 
MATERIEL-LOCATION  EFFECTIVE  TIME 
MATERIEL-LOCATION  REASON  TEXT 
MATERIEL-LOCATION  SEQUENCE  IDENTIFIER 

. 

FEATURE-LOCATION 


'feature-location  IDENTIFIER 

FEATURE  IDENTIFIER 

LOCATION  IDENTIFIER  (FK) 

FEATURE-LOCATION  TYPE  CODE 

FEATURE-LOCATION  DURATION  QUANTITY 
FEATURE-LOCATION  EFFECTIVE  CALENDAR  DATE-TIME 
FEATURE-LOCATION  SEQUENCE  IDENTIFIER 
FEATURE-LOCATION  ACCURACY  EVALUATION  CODE 
FEATURE-LOCATION  DESCRIPTION  TEXT 

FEATURE-LOCATION  END  CALENDAR  DATE-TIME 
FEATURE-LOCATION  RELIABILITY  EVALUATION  CODE 

V  J 

locates 

Figure  A-21.  AlC DM  Structures  for  Specifying  Battlefield  Object  Location 

•  Creating  new  PERSON-LOCATION  and  MATERIEL-LOCATION  entities  that  model  the  new 
loeations,  and  assoeiating  them  with  the  moved  personnel  and  materiel. 

•  Deerementing  the  supplies  needed  to  support  the  reeovery  operation  (see  See- 
tion  A.1.9). 

•  Changing  the  following  attributes  of  the  respeetive  *-OPERATIONAL-STATUS  entities: 


-  *-C0DE,  whieh  deseribes  the  eondition  of  a  person  or  materiel  (ready  vs.  out  of 
aetion,  e.g.). 

-  ^-PROTECTION  LEVEL  CODE,  whieh  deseribes  level  of  vulnerability  of  a  person 
or  materiel.  (ABOVE  GROUND  and  BUNKERED  for  materiel). 

If  the  M&S  system  models  quantities,  then  the  AICDM  eannot  model  the  effeet  of  the 
method.  The  AICDM  earmot  reeord  a  new  loeation  for  a  quantity  of  materiel  or  persons. 


Value 
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A.1.11.  Supply  Class  (Entity  Level) 


Table  A-ll.  AlC  DM  entities  that  align  with  the  Supply  class  at  theEntity  level 


AICDM  Entity 

Suggested  By  OMSC 
Method 

Relation  to  MILITARY-UNIT 

•  PERSON-TYPE- 
ORGANIZATION- 
HOLDING-ESTIMATE 

•  MATERIEL-ITEM- 
ORGANIZATION- 
HOLDING-ESTIMATE 

•  PERSON 

•  MATERIEL 

•  PERSON-OPERATIONAL- 
STATUS 

•  MATERIEL- 
OPERATIONAL-STATUS 

•  ORGANIZATION-TYPE- 
CAPABILITY-NORM 

•  ORGANIZATION- 
CAPABILITY-ESTIMATE 

•  getRemainingCapacityO 

•  getTotaiCapacityO 

•  getOtyOnHandO 

•  expendO 

•  transfer!) 

A  MILITARY-UNIT  has  associated 
MATERIEL-ITEM  and  PERSON-TYPE  enti¬ 
ties.  The  association  (HOLDING  entities) 
records  the  number  of  entities.  See 
FigureA-19. 

A  MILITARY-UNIT  has  associated  PERSON 
and  MATERIEL  entities.  Each  has  an  as¬ 
sociated  operational  status.  See  Figure 
A-20. 

A  MILITARY-UNIT  has  associated 
CAPABILITY-ESTIMATE  entities  that  can 
describe  maximum  capacity.  A 
MILITARY-UNIT  also  has  an  associated 
ORGANIZATION-TYPE,  which  has  associ¬ 
ated  ORGANIZATION-TYPE-CAPABILITY- 
NORM  entities  that  can  describe  capac¬ 
ity.  See  Figure  A-22. 

The  degree  of  Entity  level  alignment  of  the  Supply  elass  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (75%). 


A.i.ii.i.ThegetRemainingCapacity()  Method  (State  Level) 

The  following  ambiguities  in  getRemainingCapacityO  limit  the  alignment  analysis: 

•  The  OMSC  does  not  deseribe  how  eapaeity  is  expressed.  It  is  therefore  impossible  to 
determine  if  the  AICDM  has  an  attribute  that  eaptures  eapaeity  as  defined  by  the 
OMSC. 

This  analysis  assumes  that  eapaeity  is  expressed  in  the  form  used  by  AICDM  attrib¬ 
utes,  where  possible.  If  that  does  not  always  turn  out  to  be  true,  alignment  ean  still  be 
implemented  automatieally  using  a  translation  program. 

This  method  aligns  indireetly  to  the  AICDM.  Its  value  would  be  eomputed  as  the  differ- 
enee  between  getTotalCapacityO  and  getQtyOnHandO.  Its  degree  of  alignment  is  therefore  the 
minimum  of  the  degrees  of  alignment  of  these  two  methods  (75%). 
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A.i.ii.2.ThegetTotalCapacity()  Method  (State  Level) 

The  following  ambiguities  in  getTotalCapacityO  limit  the  alignment  analysis: 


The  OMSC  does  not  deseribe  how  eapaeity  is  expressed.  It  is  therefore  impossible  to 
determine  if  the  AICDM  has  an  attribute  that  eaptures  eapaeity  as  defined  by  the 


OMSC. 


This  analysis  assumes  that  eapaeity  is  expressed  in  the  form  used  by  AICDM  attrib¬ 
utes,  where  possible.  If  that  does  not  always  turn  out  to  be  true,  alignment  ean  still  be 
implemented  automatieally  using  a  translation  program. 

There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  with  respeet  to  the  getTotalCapacityO  method.  The  AICDM  ean  model  total  eapaeity 
for  an  organization  using  two  entities: 

1.  The  ORGANIZATION-CAPABILITY-ESTIMATE  entity,  whieh  models  eapaeities  for  a  IvalueI 
speeifie  organization.  An  ORGANIZATION-CAPABILITY-ESTIMATE  is  assoeiated  with  a 
CAPABILITY.  The  CAPABILITY  defines  the  type  of  eapability.  The  ORGANIZATION- 
CAPABILITY-ESTIMATE  defines  the  aetual  eapaeity.  Using  these  entities,  the  value  re¬ 
turned  by  getTotalCapacityO  should  be  equal  to  the  value  of  the  ORGANIZATION- 
CAPABILITY-ESTIMATE  MEASUREMENT  UNIT  OUANTITY  attribute  (see  Figure  A-22). 

2.  The  ORGANIZATION-TYPE-CAPABILITY-NORM  entity,  whieh  models  eapaeity  for  a  IvalueI 
type  of  organization.  An  ORGANIZATION-TYPE-CAPABILITY-NORM  is  also  assoeiated 

with  a  CAPABILITY.  Using  these  entities,  the  value  returned  by  getTotalCapacityO 
should  be  equal  to  the  value  of  the  ORGANIZATION-TYPE-CAPABILITY-NORM 
MEASUREMENT  UNIT  OUANTITY  attribute  (see  Figure  A-22). 


However,  the  CAPABILITY  TYPE  CODE  values  do  not  inelude  eategories  to  eover  many  of 
the  eapaeities  that  an  M&S  system  must  measure.  Therefore,  AICDM  and  the  OMSC 
eannot  be  eonsidered  to  be  in  perfeet  alignment  with  respeet  to  the  getTotalCapacityO 
method  at  the  State  level. 


Value 
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MATERIEL-CAPABILITY-ESTIMATE _ 

CAPABILITY  IDENTIFIER  (FK) 

MATERIEL  IDENTIFIER 

MATERIEL-CAPABILITY-ESTIMATE  IDENTIFIER 


Estimating  ORGANIZATION  Identifier 

MATERIEL-CAPABILITY-ESTIMATE  ACCURACY  EVALUATION  CODE 
MATERIEL-CAPABILITY-ESTIMATE  CALENDAR  DATE-TIME 
MATERIEL-CAPABILITY-ESTIMATE  MEASUREMENT  UNIT  QUANTITY 
MATERIEL-CAPABILITY-ESTIMATE  RELIABILITY  EVALUATION  CODE  •- 

_ / 


ACTION-RESOURCE-REQUIRED-CAPABILITY 

ACTION-RESOURCE  IDENTIFIER 
CAPABILITY  IDENTIFIER  (FK) 

ACTION  IDENTIFIER 


ACTION-RESOURCE-REQUIRED-CAPABILITY  QUANTITY 

-  - 


is  used  in 


is  described  in 


PERSON-TYPE-CAPABILITY-NORM 


FACILITY-CAPABILITY-ESTIMATE _ 

f  CAPABILITY  IDENTIFIER  (FK) 

FACILITY  IDENTIFIER 

FACILITY-CAPABILITY-ESTIMATE  IDENTIFIER 


J  Estimating  ORGANIZATION  Identifier 

FACILITY-CAPABILITY-ESTIMATE  ACCURACY  EVALUATION  CODE 
FACILITY-CAPABILITY-ESTIMATE  CALENDAR  DATE-TIME 
FACILITY-CAPABILITY-ESTIMATE  MEASUREMENT  UNIT  QUANTITY 
FACILITY-C>U»ABILITY-ESTIMATE  RELIABILITY  EVALUATION  CODE 
FACILITY-C>U»ABILITY-ESTIMATE  AVAILABLE  CAPABILITY  RATE 
FACILITY-CW»ABILITY-ESTIMATE  NON-OPTIMAL  OPERATION  ESTIMATE  CODE 
_  _ 


is  used  in 


FEATURE-TYPE-CAPABILITY-NORM 


CAPABILITY  IDENTIFIER  (FK) 

FEATURE-TYPE  IDENTIFIER 

FEATURE-TYPE-CAPABILITY-NORM  MEASUREMENT  UNIT  QUANTITY 


PERSON-CAPABILITY-ESTIMATE 


CAPABILITY  IDENTIFIER  (FK) 

PERSON  IDENTIFIER 

PERSON-CAPABILITY-ESTIMATE  IDENTIFIER 
Estimating  ORGANIZATION  Identifier 

PERSON-CAPABILITY-ESTIMATE  ACCURACY  EVALUATION  CODE 
PERSON-CAPABILITY-ESTIMATE  CALENDAR  DATE-TIME 
PERSON-CAPABILITY-ESTIMATE  MEASUREMENT  UNIT  QUANTITY 
PERSON-CAPABILITY-ESTIMATE  RELIABILITY  EVALUATION  CODE 
PERSON-CAPABILITY-ESTIMATE  NON-OPTIMAL  OPERATION  ESTIMATE  CODE 


FACILITY-TYPE-CAPABILITY-NORM 
is  used  in  J  CAPABILITY  IDENTIFIER  (FK) 
- •  FACILITY-TYPE  CODE 


FACILITY-TYPE-CAPABILITY-NORM  MEASUREMENT  UNIT  QUANTITY 
FACILITY-TYPE-CAPABILITY-NORM  AVERAGE  QUANTITY 


ORGANIZATION-TYPE-CAPABILITY-NORM 


is  used  in 

CAPABILITY  IDENTIFIER  (FK) 

ORGANIZATION-TYPE  IDENTIFIER 

ORGANIZATION-TYPE-CAPABILITY-NORM  MEASUREMENT  UNIT  QUANTITY 

* 

FEATURE-CAPABILITY-ESTIMATE 

CAPABILITY  IDENTIFIER  (FK) 

FEATURE  IDENTIFIER 

CAPABILITY  IDENTIFIER 


MATERIEL-ITEM-CAPABILITY-NORM 


CAPABILITY  IDENTIFIER  (FK) 
MATERIEL-ITEM  IDENTIFIER 


MATERIEL-ITEM-CAPABILITY-NORM  MEASUREMENT  UNIT  QUANTITY 


CAPABILITY  NAME 
CAPABILITY  TYPE  CODE 
din  MEASURE-UNIT  CODE  (FK) 

-  CAPABILITY  DESCRIPTION  TEXT 

MEASURE-UNIT  RATE  CODE  (FK) 


FEATURE-CAPABILITY-ESTIMATE  IDENTIFIER 


Estimating  ORGANIZATION  Identifier 

FEATURE-CAPABILITY-ESTIMATE  ACCURACY  EVALUATION  CODE 
FEATURE-CAPABILITY-ESTIMATE  CALENDAR  DATE-TIME 
FEATURE-CAPABILITY-ESTIMATE  MEASUREMENT  UNIT  QUANTITY 
FEATURE-CAPABILITY-ESTIMATE  RELIABILITY  EVALUATION  CODE 
FEATURE-CAPABILITY-ESTIMATE  NON-OPTIMAL  OPERATION  ESTIMATE  CODE 


ORGANIZATION-CAPABILITY-ESTIMATE _ 

ORGANIZATION  IDENTIFIER 
CAPABILITY  IDENTIFIER  (FK) 

ORGANIZATION-CAPABILITY-ESTIMATE  IDENTIFIER 

MEASURE-UNIT  CODE  (FK) 

Estimating  ORGANIZATION  Identifier 

ORGANIZATION-CAPABILITY-ESTIMATE  ACCURACY  EVALUATION  CODE 
ORGANIZATION-CAPABILITY-ESTIMATE  CALENDAR  DATE-TIME 
ORGANIZATION-CAPABILITY-ESTIMATE  RELIABILITY  EVALUATION  CODE 
ORGANIZATION-CAPABILITY-ESTIMATE  MEASUREMENT  UNIT  QUANTITY 
MEASURE-UNIT  RATE  CODE  (FK) 


ordinate  is  convertible  to  MEASURE-UNIT-CONVERSION 


MEASURE-UNIT _ 

pertains  to  J  MEASURE-UNIT  CODE 

^  MEASURE-UNIT  RATE  CODE 


subordinate  (FK) 
ordinate  (FK) 

MEASURE-UNIT-CONVERSION  ALGORITHM  TEXT 


subordinate  is  convertible  to 


Figure  A-22.  AlCDM  Structures  for  Specifying  Capability 
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A.i.ii.3.ThegetQtyOnHand()  Method  (State  Level) 

There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  getQtyOnHandO  method.  Assuming  the  result  of  getQtyOnHandO  is 
an  integer: 

•  If  the  M&S  system  models  entities,  it  should  be  the  number  of  MATERIEL- 
ORGANIZATION  (or  PERSON-ORGANIZATION)  instances  related  to  the  ORGANIZATION  in 
question.  (Note  that  PERSON-ORGANIZATION  includes  a  timestamp  attribute.  This  at¬ 
tribute  would  qualify  the  instances  counted  in  the  relationship.  MATERIEL- 
ORGANIZATION  has  no  such  attribute.  For  this  reason,  State  level  alignment  is  not  per¬ 
fect.) 

•  If  the  M&S  system  models  entity  quantity,  it  should  be  the  value  of  the  appropriate 
HOLDING-ESTIMATE  OUANTITY  attribute. 

In  most  M&S  systems,  the  result  of  getQtyOnHandO  will  be  an  integer.  Occasionally,  quan¬ 
tity  will  be  expressed  in  non-integer  values.  The  AICDM  cannot  model  these  quantities. 
This  is  another  reason  why  State  level  alignment  is  not  perfect. 

A.i.ii.4.Theexpend()  Method  (State  Level) 

This  is  a  behavioral  method.  It  should  align  to  the  same  attributes  as  getQtyOnHandO 
(75%).  The  difference  in  values  returned  by  getQtyOnHandO  before  and  after  expend!)  is  in¬ 
voked  should  equal  the  amount  specified  to  be  transferred  by  the  parameters  to  expend!). In 
other  words,  this  method  aligns  to  the  OMSC  to  the  same  degree  that  getQtyOnHand!)  does. 

A.1.11.5.  The  transfer 0  Method  (State  Level) 

The  transfer!)  method  is  a  behavioral  method.  It  should  align  to  the  same  attributes  as 
getQtyOnHand!).  The  difference  in  values  returned  by  getQtyOnHand!)  before  and  after 
transfer!)  is  invoked  should  equal  the  amount  specified  to  be  transferred  by  the  parameters 
to  transfer!),  both  for  the  sender  and  the  receiver.  In  other  words,  this  method  aligns  to  the 
OMSC  to  the  same  degree  that  getQtyOnHand!)  does  (75%). 

A.1.12.  C2  Class  (Entity  Level) 


Table  A- 12.  AICDM  entities  that  align  with  the  C2  class  at  the  entity  level 


AICDM 

Entity 

Suggested 
By  OMSC 
Method 

Relation  to  MILITARY-UNIT 

•  ACTION 

•  PLAN 

•  MISSION 

•  TASK 

doC2!) 

A  MILITARY-UNIT  has  associated  ACTION,  MISSION,  and  PLAN  enti¬ 
ties.  A  MISSION  consists  of  TASK  entities.  See  Figure  A-12. 
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The  degree  of  Entity  level  alignment  of  the  C  2  class  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (0%). 


A.i.i2.i.ThedoC2()  Method  (State  Level) 

The  description  of  the  doC2()  method  is  highly  generic.  It  is  impossible  to  determine  any¬ 
thing  about  the  State  level  at  this  time.  There  is  no  State  level  alignment  (0%)  between 
the  AICDM  and  the  OMSC  with  respect  to  the  doC2()  Method. 

A.2  Platform  Standard  Object  (Conceptual  Level) 

The  OMSC  defines  Platform  as  follows  [HB  1998B]: 

A  platform  can  be  any  entity  of  interest  in  the  model.  Examples  include  vehicles 
of  all  types,  individuals/p ersons,  individual  systems  (i.e.,  radar  systems),  a  mis¬ 
sile,  etc. 

The  class  Platform  is  the  focal  class  of  the  Platform  standard  object. 

The  AICDM  does  not  contain  any  single  entity  that  corresponds  to  the  OMSC  concept  of 
a  platform.  It  does  contain  many  entities  capturing  different  aspects  of  different  types  of 
platforms.^  The  MATERIEL  and  AIRCRAFT  entities  can  model  vehicles.  The  PERSON  entity 
can  model  persons.  The  FACILITY  entity  in  the  AICDM  can  model  non-mobile  platforms 
(e.g.,  missile  silos). 

Since  different  entities  in  the  AICDM  map  to  different  platforms,  there  is  no  single  focal 
entity  in  the  AICDM  for  the  OMSC  concept  of  Platform.  Instead,  there  are  four  focal  enti¬ 
ties:  MATERIEL,  AIRCRAFT,  FACILITY,  and  PERSON. 

Table  A- 13  contains  those  AICDM  entities  and  relationships  that  best  capture  the  OMSC 
concept  of  a  platform.  For  each  OMSC  class,  Table  A- 13  has  four  rows,  one  for  each  fo¬ 
cal  entity.  The  relationships  between  the  four  focal  entities  and  relevant  related  entities 
are  shown  in  the  ER  diagrams  in  Figure  A-23  and  Figure  A-24. 

Many  of  these  entities  and  relationships  come  from  parts  of  the  AICDM  that  are  marked 
as  “to  be  worked”  by  the  Army  Data  Management  Group  at  Fort  Belvoir.  Hence,  the 
mappings  below  for  the  Platform  standard  object  are  tentative,  pending  further  work  on 
the  AICDM.  Substantive  changes  are  possible. 


A  proposal  to  add  entities  describing  platform  types  to  the  AICDM  is  under  consideration  by  the  Army 
Data  Management  Group  at  Fort  Belvoir. 
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Table  A- 13.  AlC  DM  Entities  that  Align  with  Classes  of  the  Platform  Standard  Ob¬ 
ject  at  the  Conceptual  Level 


OMSC  Class 

Related 

AICDM  Entity 

Relationship  to 
Corresponding  Focal  Entity 

Platform 

(ground,  water, 
space  platforms) 

MATERIEL^ 

Identical  to  focal  entity. 

Platform 
(air  platform) 

AIRCRAFT 

Identical  to  focal  entity. 

Platform 

(person  platform) 

PERSON 

Identical  to  focal  entity. 

Platform 

(static  ground  plat¬ 
form) 

FACILITY 

Identical  to  focal  entity. 

Sensor  (ground,  wa¬ 
ter,  and  space  plat¬ 
forms) 

MATERIEL,  categorized  as 
SENSOR-TYPE 

MATERIEL  has  associated  MATERIEL,  describ¬ 
ing  a  vehicle  platform's  sensors.  MATERIEL 
has  an  associated  MATERIEL-ITEM  that  de¬ 
scribes  its  type.  SENSOR-TYPE  is  a  subtype 
of  MATERIEL-ITEM.  See  Figure  A-23. 

Sensor  (air  platform) 

None. 

The  AICDM  does  not  associate  sensors 
with  aircraft. 

Sensor  (person  plat¬ 
form) 

MATERIEL,  categorized  as 
SENSOR-TYPE 

PERSON  has  associated  MATERIEL,  describing 
a  person's  sensors.  MATERIEL  has  an  associ¬ 
ated  MATERIEL-ITEM,  of  which  SENSOR-TYPE 
is  a  subtype.  See  Figure  A-23. 

Sensor  (static  plat¬ 
form) 

MATERIEL,  categorized  as 
SENSOR-TYPE 

FACILITY  has  associated  MATERIEL,  describing 
a  static  platform's  sensors.  MATERIEL  has  an 
associated  MATERIEL-ITEM,  of  which  SENSOR- 
TYPE  is  a  subtype.  See  Figure  A-24. 

Weapon  (ground,  wa¬ 
ter,  and  space  plat¬ 
forms) 

MATERIEL,  categorized  as 
WEAPON-TYPE 

MATERIEL  has  an  associated  MATERIEL-ITEM 
that  describes  its  type.  WEAPON-TYPE  is  a 
subtype  of  MATERIEL-ITEM.  See  Figure  A-23. 

Weapon  (air  plat¬ 
form) 

None. 

The  AICDM  does  not  associate  weapons 
with  individual  aircraft. 

Weapon  (person  plat¬ 
form) 

MATERIEL,  categorized  as 
WEAPON-TYPE 

PERSON  has  associated  MATERIEL,  describing 
a  person's  weapons  MATERIEL  has  an  associ¬ 
ated  MATERIEL-ITEM,  of  which  WEAPON-TYPE 
is  a  subtype.  See  Figure  A-23. 

Weapon  (static  plat¬ 
form) 

MATERIEL,  categorized  as 
WEAPON-TYPE 

FACILITY  has  associated  MATERIEL,  describing 
a  static  platform's  weapons.  MATERIEL  has 
an  associated  MATERIEL-ITEM,  of  which 
WEAPON-TYPE  is  a  subtype.  See  Figure  A-24. 

^  The  DDA  contains  separate  entities  for  SHIP  and  SATELLITE.  We  recommend  including  these  entities 
in  the  AICDM  to  address  M&S  requirements  for  water  and  space  platforms. 
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OMSC  Class 

Related 

AlCDM  Entity 

Relationship  to 
Corresponding  Focal  Entity 

Movement 
(ground,  water, 
space  platforms) 

LOCATION 

MATERIEL  can  have  an  associated  LOCATION. 
SeeFigureA-23. 

Movement  (person 
platform) 

LOCATION 

PERSON  can  have  an  associated  LOCATION. 
SeeFigureA-23. 

Movement  (air  plat¬ 
forms) 

LOCATION 

The  AlCDM  does  not  associate  a  location 
with  an  aircraft. 

Movement  (static 
platforms) 

N/A 

A  static  platform  is  incapable  of  motion. 

•  Logistics 

•  Suppiy 

(ground,  water,  and 
space  piatforms) 

MATERIEL-ITEM-MATERIEL¬ 

HOLDING-ESTIMATE 

MATERIEL  Is  inventoried  by  MATERIEL-ITEM- 
MATERIEL-HOLDING-ESTIMATE.  See  Figure 

A-23. 

•  Logistics 

•  Suppiy 

(air  platform) 

None 

The  AlCDM  does  not  associate  logistical 
information  with  aircraft. 

•  Logistics 

•  suppiy 

(person  platform) 

MATERIEL-ITEM-PERSON- 

HOLDING-ESTIMATE 

PERSON  is  inventoried  by  MATERIEL-ITEM- 
PERSON-HOLDING-ESTIMATE.  See  Figure  A-23. 

•  Logistics 

•  Suppiy 
(static  piatforms) 

MATERIEL-ITEM-FACILITY- 

HOLDING-ESTIMATE 

FACILITY  is  inventoried  by  MATERIEL-ITEM- 
FACILITY-HOLDING-ESTIMATE.  SeeFigureA-24. 

Maintenance  (ground, 
water,  and  space 
platforms) 

•  MATERIEL-CAPABILITY- 
ESTIMATE 

•  MATERIEL- 
OPERATIONAL-STATUS 

MATERIEL  Is  the  subject  of  MATERIEL- 
CAPABILITY-ESTIMATE.  MATERIEL  Is  described 
by  MATERIEL-OPERATIONAL-STATUS.  See 

Figure  A-23. 

Maintenance  (air  plat¬ 
forms) 

None 

The  AlCDM  does  not  associate  mainte¬ 
nance  information  with  aircraft. 

Maintenance  (person 
platforms) 

•  PERSON-CAPABILITY- 
ESTIMATE 

•  PERSON-OPERATIONAL- 
STATUS 

PERSON  isthe  subject  of  PERSON-CAPABILITY- 
ESTIMATE.  PERSON  is  described  by  PERSON- 
OPERATIONAL-STATUS.  SeeFigureA-23. 

Maintenance  (static 
platforms) 

•  FACILITY-CAPABILITY- 
ESTIMATE 

•  FACILITY-OPERATIONAL- 
STATUS 

FACILITY  is  the  subject  of  FACILITY-CAPABILITY- 
ESTIMATE.  FACILITY  is  described  by  FACILITY- 
OPERATIONAL-STATUS.  SeeFigureA-24. 

Crew  (ground,  water, 
and  space  platforms) 

•  PERSON 

•  PERSON-TYPE 

•  PERSON-TYPE- 
MATERIEL-HOLDING- 
ESTIMATE 

A  MATERIEL  platform  has: 

•  Associated  PERSON  entities. 

•  An  associated  PERSON-TYPE-MATERIEL- 
HOLDING-ESTIMATE. 

PERSON-TYPE  isthe  type  for  PERSON. 

SeeFigureA-23. 

Crew  (air  platforms) 

None. 

The  AlCDM  does  not  associate  crew  infor¬ 
mation  with  aircraft. 
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OMSC  Class 

Related 

AlCDM  Entity 

Relationship  to 
Corresponding  Focal  Entity 

Crew  (person  plat¬ 
forms) 

N/A 

N/A 

Crew  (static  plat¬ 
forms) 

•  PERSON 

•  PERSON-TYPE 

•  PERSON-TYPE-FACILITY- 
HOLDING-ESTIMATE 

A  FACILITY  platform  has: 

•  Associated  PERSON  entities. 

•  An  associated  PERSON-TYPE-FACILITY- 
HOLDING-ESTIMATE. 

A  PERSON  has  an  associated  PERSON-TYPE. 

See  Figure  A-24. 

Communications 

TELECOMMUNICATIONS- 

NETWORK-ELEMENT 

The  AlCDM  does  not  relate  a 
TELECOMMUNICATIONS-NETWORK-ELEMENT  to 
any  of  the  focal  entities  for  this  view. 

Carrier  (ground,  wa¬ 
ter,  and  space  plat¬ 
forms) 

•  MATERIEL 

•  MATERIEL-ITEM- 
MATERIEL-HOLDING- 
ESTIMATE 

•  MATERIEL-ITEM 

•  VEHICLE-TYPE 

•  PERSON 

•  PERSON-TYPE- 
MATERIEL-HOLDING- 
ESTIMATE 

•  PERSON-TYPE 

MATERIEL  has: 

•  Associated  MATERIEL  and  PERSON  entities, 
for  associating  instances. 

•  Associated  MATERIEL-ITEM  and  PERSON- 
TYPE  entities,  for  associating  types. 

MATERIEL-ITEM  identifies  EOUIPMENT-TYPE 
and  VEHICLE-TYPE. 

See  Figure  A-23. 

Carrier  (person  plat¬ 
form) 

•  MATERIEL 

•  MATERIEL-ITEM- 
PERSON-HOLDING- 
ESTIMATE 

•  MATERIEL-ITEM 

•  VEHICLE-TYPE 

•  PERSON 

•  PERSON-TYPE 

PERSON  has: 

•  Associated  MATERIEL  and  PERSON  entities, 
for  associating  instances. 

•  Associated  MATERIEL-ITEM  entities,  for 
associating  types. 

MATERIEL-ITEM  identifies  VEHICLE-TYPE. 

See  Figure  A-23. 

Carrier  (air  platform) 

None. 

The  AlCDM  does  not  model  relationships 
between  AIRCRAFT  and  materiel  or  persons. 

Carrier  (static  plat¬ 
form) 

N/A 

Static  platforms  are  not  carriers. 

PlatformFrame 
(ground,  water,  and 
space  platforms) 

•  EOUIPMENT-TYPE 

•  VEHICLE-TYPE 

MATERIEL  has  associated  MATERIEL-ITEM  enti¬ 
ties.  MATERIEL-ITEM  identifies  EOUIPMENT- 
TYPE  and  VEHICLE-TYPE.  See  Figure  A-23. 

PlatformFrame  (air 
platforms) 

AIRCRAFT  categorized  as 
AIRCRAFT-TYPE 

AIRCRAFT-TYPE  categorizes  AIRCRAFT. 

PlatformFrame  (person 
platforms) 

PERSON 

Identical  to  focal  entity. 

PlatformFrame  (static 
platforms) 

None. 

The  AlCDM  does  not  contain  relevant  in¬ 
formation  for  facilities. 

FrameComponent 
(ground,  water,  and 
space  platforms) 

MATERIEL,  categorized  as 
EOUIPMENT-TYPE 

MATERIEL  has  associated  MATERIEL-ITEM  enti¬ 
ties  MATERIEL-ITEM  identifies  EOUIPMENT- 
TYPE.  See  Figure  A-23. 
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OMSC  Class 

Related 

AlCDM  Entity 

Relationship  to 
Corresponding  Focal  Entity 

FrameComponent  (air 
platforms) 

None. 

The  AlCDM  does  not  model  aircraft  com¬ 
ponent  relationships. 

FrameComponent 
(person  platforms) 

N/A 

A  person  is  considered  atomic. 

FrameComponent 
(static  platforms) 

MATERIEL,  categorized  as 
EQUIPMENT-TYPE 

FACILITY  has  associated  MATERIEL-ITEM  enti¬ 
ties.  MATERIEL-ITEM  identifies  EQUIPMENT- 
TYPE.  See  Figure  A-24. 

The  degree  of  Conceptual  level  alignment  of  the  Platform  standard  object  is  the  average  of 
the  degrees  of  alignment  of  its  classes  (48%). 
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Figure  A-23.  Relations  for  Ground,  Water,  Space,  and  Person  Platforms 
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is  the  type  for 


Figure  A-24.  Relations  for  Static  Platforms 


A.2.1.  Platform  Class  (Entity  Level) 

The  P  latform  class  can  model  either  a  person  or  an  individual  system.  If  it  is  a  person,  it 
aligns  with  the  AICDM  entity  P  E  R  S  0  N .  If  it  is  an  individual  system,  it  aligns  with: 

•  MATE  R  IE  L  for  ground,  water,  and  space  platforms. 

•  AIRCRAFT  for  air  platforms. 

•  FACILITY  for  static  platforms. 

The  names  of  the  methods  in  class  Platform  suggest  that  the  AICDM  entities  in  Table  A- 14 
align  with  Platform  at  the  entity  level,  as  indicated. 


Table  A- 14.  AICDM  entities  that  align  to  the  Platform  class  at  the  Entity  level 


AICDM  Entity 

Suggested  By 
OMSC 
Method 

Relation  to  Focal  Entity 

MATERIEL  (for  ground,  water,  and 
space  platforms) 

N/A 

Identical  to  focal  entity. 

PERSON  (for  person  platforms) 

N/A 

Identical  to  focal  entity. 

AIRCRAFT  (for  air  platforms) 

N/A 

Identical  to  focal  entity. 
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AlCDM  Entity 

Suggested  By 
OMSC 
Method 

Relation  to  Focal  Entity 

FACILITY  (for  static  platforms) 

N/A 

Identical  to  focal  entity. 

MATERIEL-ITEM  and  its  subtypes 
(for  ground,  water,  and  space 
platforms) 

getTypeO 

MATERIEL-ITEM  is  the  class  for  MATERIEL 

PERSON-TYPE  (for  person  plat¬ 
forms) 

getTypeO 

PERSON-TYPE  is  the  type  for  PERSON 

•  AIRCRAFT-TYPE 

•  MILITARY-AIRCRAFT-TYPE 
(for  air  platforms) 

getTypeO 

AIRCRAFT-TYPE  categorizes  AIRCRAFT; 
MILITARY-AIRCRAFT-TYPE  is  a  subtype  of 
AIRCRAFT-TYPE. 

FACILITY-TYPE  (for  static  plat¬ 
forms) 

getTypeO 

FACILITY-TYPE  is  the  type  for  FACILITY. 

MATERIEL-OPERATIONAL-STATUS  (for 
ground,  water,  and  space  plat¬ 
forms) 

getStatusO 

MATERIEL  originates  MATERIEL- 
OPERATIONAL-STATUS. 

PERSON-OPERATIONAL-STATUS  (for 
person  platforms) 

getStatusO 

PERSON  originates  PERSON- 
OPERATIONAL-STATUS. 

FACILITY-OPERATIONAL-STATUS 

getStatusO 

FACILITY  is  described  by  FACILITY- 
OPERATIONAL-STATUS. 

The  LOCATION  view 

getLocationO 

A  MATERIEL,  PERSON,  or  FACILITY  has  an 
associated  CONTROL-FEATURE,  which 
has  an  associated  LOCATION. 

•  ORGANIZATION 

•  ORGANIZATION-ASSOCIATION 

(for  ground,  water,  space,  person, 
and  static  platforms) 

getSideO 

A  MATERIEL,  PERSON,  or  FACILITY  has  an 
associated  ORGANIZATION,  which  has  a 
side  (see  Section  A. 1.1.4). 

•  PERSON 

•  PERSON-OPERATIONAL-STATUS 

•  MATERIEL-OPERATIONAL-STATUS 
(for  ground,  water,  space,  person, 
and  static  platforms) 

assessDamageO 

PERSON,  MATERIEL,  and  FACILITY  have 
an  associated  OPERATIONAL-STATUS. 

The  degree  of  Entity  level  alignment  of  the  P  latform  class  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (62%). 


A.2.i.i.ThegetType()  Method  (State  Level) 

The  following  ambiguities  in  getTypeO  limit  alignment  analysis: 

•  The  OMSC  does  not  define  what  a  type  designation  is.  Assuming  that  Platform  is  a 
virtual  class  and  that  actual  platform  instances  would  be  members  of  subtypes  of  Plat¬ 
form,  the  type  designation  is  probably  just  an  identifying  string  that  gives  the  name  of 
the  subtype. 

Assume  the  type  designation  is  a  string. 
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There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  getTypeO  method: 

•  If  the  Platform  is  materiel,  it  can  be  modeled  by  the  MATERIEL-ITEM  entity’s  MATERIEL- 
ITEM  TYPE  CODE  attribute,  or  perhaps  the  MATERIEL-ITEM  NAME. 

•  If  the  Platform  is  a  person,  the  type  designation  might  be  “Person”.  It  might  also  be 
the  person’s  rank  or  role.  This  information  can  come  from  the  PERSON -TYPE 
CATEGORY  CODE  and  the  UNIFORMED-SERVICE-RANK  CODE  attributes  of  PERSON-TYPE. 

•  If  the  Platform  is  a  facility,  the  type  designation  could  come  from  either  of  the  attrib¬ 
utes  FACILITY -TYPE  CODE  or  FACILITY -TYPE  CATEGORY  CODE. 

The  uncertainties  as  to  which  attribute  is  appropriate  precludes  perfect  alignment. 

A.2.1.2. The  getStatusO  Method  (State  Level) 

There  is  perfect  State  level  alignment  (100%)  between  the  AICDM  and  the  OMSC  with 
respect  to  the  getStatusO  method: 

•  If  the  platform  is  a  Person: 

-  PERSON  has  an  attribute  PERSON -ST  AT  US -CODE  that  can  represent  alive/dead 
values. 

-  PERSON-OPERATIONAL-STATUS  has  an  attribute  PERSON-OPERATIONAL-STATUS 
CODE  that  captures  status  with  enough  values  to  model  the  standard  kill  cate¬ 
gories. 

•  If  the  platform  is  MATERIEL,  the  MATERIEL-OPERATIONAL-STATUS  CODE  attribute  cap¬ 
tures  the  status  of  equipment  with  enough  values  to  model  the  standard  kill  catego¬ 
ries. 

•  If  the  platform  is  a  FACILITY,  the  FACILITY-OPERATIONAL-STATUS  CODE  attribute  cap¬ 
tures  the  status  of  equipment  with  enough  values  to  model  the  standard  kill  catego¬ 
ries. 

A.2.i.3.ThegetLocation()  Method  (State  Level) 

The  getLocatlonO  method  for  platforms  can  be  considered  analogous  to  the  getLocatlonO 
method  for  units.  These  methods  align  to  the  same  degree  (37%).  See  Section  A. 3. 

A.2.i.4.The  getSideO  Method  (State  Level) 

The  getSIdeO  method  for  platforms  can  be  considered  analogous  to  the  getSIdeO  method  for 
units.  These  methods  align  to  the  same  degree  (75%).  See  Section  A.  1.1. 4. 
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A.2.i.5.TheassessDamage()  Method  (State  Level) 

The  following  ambiguities  in  assessDamageO  limit  the  alignment  analysis: 


•  The  OMSC  does  not  specify  how  the  amount  of  damage  is  determined. 

•  The  OMSC  does  not  specify  units  in  which  damage  is  measured. 

There  is  a  low  degree  of  State  level  alignment  (25%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  assessDamageO  method.  The  MATERIEL-OPERATIONAL-STATUS, 
PERSON-OPERATIONAL-STATUS,  and  FACILITY-OPERATIONAL-STATUS  entities  have  a  CODE 
attribute.  This  attribute  describes  the  condition  of  the  entity. 

However,  the  domains  of  the  CODE  attributes  do  not  capture  the  nuances  of  damage. 


Value 


A.2.2.  Sensor  Class  (Entity  Level) 


Table  A- 15.  AICDM  entities  that  align  to  the  Sensor  class  attheEntity  level 


AICDM  Entity 

Suggested  By 
OMSC 
Method 

Relation  to  Focal  Entity 

SENSOR-TYPE 

getMaxRangeO 

The  focal  entities  (except  AIRCRAFT)  havean  as¬ 
sociation  with  MATERIEL,  which  has  an  associ¬ 
ated  MATERIEL-ITEM,  of  which  SENSOR-TYPE  is  a 
subtype. 

None 

getOrientationO 

N/A 

PERSON 

getContactsO 

N/A 

FACILITY 

getContactsO 

MATERIEL-ITEM 

getContactsO 

MATERIEL-ITEM  is  the  class  for  MATERIEL 

ORGANIZATION 

getContactsO 

MATERIEL  has  a  many-to-many  relationship  with 
ORGANIZATION: 

•  MATERIEL  is  inventoried  by  MATERIEL-ITEM- 
MATE  RIEL-HOLDING -ESTIMATE 

•  ORGANIZATION  provides  MATERIEL-ITEM- 
MATERIEL-HOLDING -ESTIMATE 

None 

activated 

N/A 

deactivated 

N/A 

The  degree  of  Entity  level  alignment  of  the  Sensor  class  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (30%). 


A.2.2.i.ThegetMaxRange()  Method  (State  Level) 

There  is  perfect  State  level  alignment  (100%)  between  the  AICDM  and  the  OMSC  with 
respect  to  the  getMaxRangeO  method.  The  SENSOR-TYPE  entity  has  an  attribute  SENSOR- 
TYPE -RANGE  MAXIMUM  DIMENSION  that  models  the  maximum  range  of  a  sensor  type. 
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A.2.2.2.ThegetOrientation()  Method  (State  Level) 


There  is  no  State  level  alignment  (0%)  between  the  AICDM  and  the  OMSC  with  respect 
to  the  getOrientationO  method.  The  AICDM  does  not  model  orientation.'*’ 


A.2.2.3.ThegetContacts()  Method  (State  Level) 

The  following  ambiguities  in  getContactsO  limit  the  alignment  analysis: 

•  The  OMSC  states  that  getContactsO  queries  a  target,  but  does  not  describe  the  result  of 
that  query. 

Assuming  that  a  target  may  be  a  PERSON,  FACILITY,  MATERIEL  entity,  or  ORGANIZATION, 
the  result  of  the  getContactsO  method  might  be  a  set  of  said  entities.  Perhaps  other  in¬ 
formation,  such  as  location  or  physical  properties,  might  be  included. 

Depending  on  the  sensor,  the  method  may  be  able  to  distinguish  friends  from  foes  (see 
Section  A.  1 . 1 .4  for  relevant  attributes). 

There  is  a  medium  degree  of  State  level  alignment  (50%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  getContactsO  method.  The  estimate  is  based  on  the  ambiguity 
described  above.  The  AICDM  does  not  model  many  physical  object  signatures.  If  the 
method  returns  signatures,  it  does  not  align  to  the  AICDM.  If  it  returns  contacted  entities 
(as  suggested  by  the  name)  it  aligns  well. 


A.2.2.4.The  activateO  and  deactivateO  Methods  (State 
Level) 


There  is  no  State  level  alignment  (0%)  between  the  AICDM  and  the  OMSC  with  respect 
to  these  methods.  The  AICDM  entity  MATERIEL-OPERATIONAL-STATUS  describes  the  opera¬ 
tional  ability  of  specific  materiel. 


The  attribute  MATERIEL-OPERATIONAL-STATUS  CODE  has  a  range  of  values  listing  various  [value 
abilities.  These  values  describe  capability  to  operate,  rather  than  actual  operation. 


A.2.3.  Weapon  Class  (Entity  Level) 


TableA-16.  AICDM  entities  that  align  to  the  Weapon  class  at  the  Entity  level 


AICDM  Entity 

Suggested  By 
OMSC 
Method 

Relation  to  Focal  Entity 

WEAPON-TYPE 

getMaxRangeO 

A  weapon  is  MATERIEL,  which  has  an  associated 

See  footnote  5. 


A-58 


AICDM  Entity 

Suggested  By 
OMSC 
Method 

Relation  to  Focal  Entity 

MATERIEL-ITEM;  WEAPON-TYPE  is  a  subtype  of  MATERIEL- 
ITEM. 

•  ACTION 

•  ACTION- 
OBJECTIVE- 
MATERIEL 

•  ACTION-VERB 

loadO 

ACTION  describes  loading.  ACTION-OBJ  ECTIVE-MATERIEL 
identifies  a  particular  weapon  as  the  object  of  loading. 
The  focal  entities  (MATERIEL,  PERSON,  etc.)  have  asso¬ 
ciations  with  weapon  MATERIEL. 

•  ACTION 

•  ACTION- 
RESOURCE- 
MATERIEL 

•  TARGET 

•  ACTION-VERB 

engageTargetO 

An  ACTION: 

•  Is  employed  against  a  TARGET. 

•  UsesACTION-RESOURCE-MATERIEL  (i.e.,  the  weapon). 

A  TARGET  has  an  association  with  the  entity 
(ORGANIZATION,  MATERIEL,  or  PERSON)  that  designated  it 
as  a  target. 

The  degree  of  Entity  level  alignment  of  the  Weapon  class  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (50%). 


A.2.3.i.ThegetMaxRange()  Method  (State  Level) 

There  is  perfect  State  level  alignment  (100%)  between  the  AICDM  and  the  OMSC  with 
respect  to  the  getMaxRangeO  method.  The  result  of  getMaxRangeO  should  equal  the  value  of 
the  WEAPON-TYPE-RANGE  MAXIMUM  DIMENSION  attribute.  Possibly  a  simulation  would  use 
the  WEAPON-TYPE  RANGE  MAXIMUM  ASSISTED  DIMENSION  attribute,  if  the  weapon  is  on  a 
carrier. 


A.2.3.2.The  loadO  Method  (State  Level) 

There  is  a  low  degree  of  State  level  alignment  (25%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  load()  method.  The  AICDM  can  model  the  action  of  loading  a 
weapon,  but  it  does  not  model  whether  a  weapon  is  loaded  or  not.  Arguably,  a  weapon’s 
state  could  be  ascertained  based  on  an  examination  of  recorded  loading  and  firing  actions, 
but  such  an  approach  seems  complex. 

ACTION-VERB  CODE  lacks  a  value  for  weapon  loading.  One  should  be  added  to  support 
M&S  system  modeling. 

A.2.3.3.TheengageTarget()  Method  (State  Level) 

The  following  ambiguities  in  engageTargetO  limit  the  alignment  analysis: 

•  The  method’s  description  states  that  it  initiates  the  weapon-firing  event.  This  might 
imply  that  weapon  firing  is  not  an  atomic  event.  The  OMSC  does  not  break  down 
weapon  firing  further. 
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This  is  a  behavioral  method.  The  AICDM  entity  ACTION  can  model  the  action  of  firing  a 
weapon.  Its  attribute  ACTION-VERB  CODE  includes  domain  values  for  weapon  firing. 

There  is  a  medium  degree  of  State  level  alignment  (50%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  engageTargetO  method.  Each  engagement  of  a  target  corre¬ 
sponds  to  an  ACTION.  The  AICDM  models  the  target  as  a  TARGET  (a  indirect  subtype  of  an 
ACTION-OBJ  ECTIVE,  which  is  associated  with  an  ACTION).  The  weapon  used  is  associated 
with  the  ACTION  as  ACTION-RESOURCE-MATERIEL.  The  TARGET  is  associated  with  the  plat¬ 
form  engaging  the  weapon  via  an  “initiates”  relationship  to  one  of  MATERIEL  (ground,  wa¬ 
ter,  and  space  platforms),  PERSON  (person  platforms),  or  FACILITY  (static  platforms). 


However,  the  AICDM  cannot  model  the  result  of  the  method  using  attributes  of  a 
WEAPON.  In  particular,  the  method  should  decrement  the  number  of  loaded  munitions  by 
one.  Modeling  this  using  the  AICDM  would  be  complex,  for  the  same  reasons  stated  for 
the  loadO  method  (see  Section  A.2.3.2). 


ACTION-VERB  CODE  has  several  domain  values  for  weapon  firing  (FIRE  FOR  EFFECT,  |value| 
PROVIDE  SPREADING  FIRE,  etc.).  None  corresponds  exactly  to  initiating  weapon  firing.  In 
any  case,  the  exact  value  assigned  to  the  attribute  presumably  depends  on  context,  i.e., 
the  type  of  mission  that  Platform  is  supporting. 


A.2.4.  Movement  Class  (Entity  Level) 

The  Movement  class  is  concerned  with  the  motion  of  a  platform.  The  class’  methods  set 
and  return  motion-related  properties. 


Table  A- 17.  AICDM  entities  that  align  to  the  Movement  class  at  the  Entity  level 


AICDM 

Entity 

Suggested  By 
OMSC 
Method 

Relation  to  MATERIEL  or  PERSON 

LOCATION 

moveToO 

MATERIEL  has  a  many-to-many  relationship  with  LOCATION. 
PERSON  has  a  many-to-many  relationship  with  LOCATION. 

None 

getVelocityO 

N/A 

None 

changeVelocityO 

N/A 

The  degree  of  Entity  level  alignment  of  the  Movement  class  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (25%). 


A.2.4.i.ThegetVelocity()  Method  (State  Level) 

There  is  no  State  level  alignment  (0%)  between  the  AICDM  and  the  OMSC  with  respect 
to  the  getVelocItyO  method.  The  AICDM  does  not  model  velocity  (see  Section  A.  1.1. 2). 
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A.2.4.2.ThechangeVelocity()  Method  (State  Level) 

There  is  no  State  level  alignment  (0%)  between  the  AICDM  and  the  OMSC  with  respect 
to  the  changeVelocityO  method.  The  AICDM  does  not  model  velocity  (see  Section  A.  1.1. 2). 

A.2.4.3.The  moveToO  Method  (State  Level) 

This  is  a  behavioral  method.  Its  behavior  is  similar  to  that  of  the  move()  method  of  the  Unit 
class  (see  Section  A.  1.1. 9).  However,  that  method  “advances  a  unit  toward  its  next  loca¬ 
tion,”  whereas  moveToO  “move[s]  directly  to  a  location”.  The  description  of  moveToO 
seems  more  specific  than  that  of  moved,  implying  the  parameters  to  moveToO  must  include 
a  Location. 

The  other  difference  is  that  the  change  of  state  for  moved  creates  a  new  association  be¬ 
tween  an  ORGANiZATiON  and  a  LOCATiON  (via  a  CONTROL-FEATURE).  Invoking  moveToO  cre¬ 
ates  anew  association  between  MATERiEL  (or  PERSON)  and  a  LOCATiON. 

There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  moveToO  method.  As  the  first  paragraph  of  this  section  states, 
moveToO  aligns  more  closely  than  UniLmoveO.  This  method  aligns  more  closely  to  the 
AICDM  than  the  UniLmoveO  method.  However,  the  AICDM  cannot  model  all  types  of  lo¬ 
cations  that  the  OMSC  uses  (see  Section  A.3).  The  alignment  is  therefore  not  perfect. 

A.2.5.  Logistics  Class  (Entity  Level) 

The  Logistics  class  is  identical  to  the  Logistics  class  for  a  Unit  (see  Section  A.  1.9),  except  that 
changes  affect  relationships  between  the  MATERiEL  entity  modeling  the  platform  and  its 
logistics  supplies,  rather  than  between  an  ORGANiZATiON  entity  modeling  a  unit.  The 
Logistics  class  of  the  P  iatform  standard  object  aligns  to  the  AICDM  to  the  same  degree  as  the 
Logistics  class  of  the  Unit  standard  object  (75%). 

A.2.6.  Supply  Class  (Entity  Level) 

The  Suppiy  class  is  identical  to  the  Suppiy  class  for  a  Unit  (see  Section  A.  1.11),  except  that 
changes  affect  relationships  between  the  MATERiEL  entity  modeling  the  platform  and  its 
logistics  supplies,  rather  than  between  an  ORGANiZATiON  entity  modeling  a  unit  and  its 
logistics  supplies.  The  Suppiy  class  of  the  P iatform  standard  object  aligns  to  the  AICDM  to 
the  same  degree  as  the  Suppiy  class  of  the  Unit  standard  object  (75%). 

A.2.7.  Maintenance  Class  (Entity  Level) 

The  Maintenance  class  models  maintenance  actions.  It  is  similar  to  the  Maintenance  class  for 
a  Unit  (see  Section  A.  1.10),  except  it  has  only  one  method  (conductMaintenanceO)  rather  than 
three.  A  platform  may  be  a  person  as  well  as  equipment,  so  the  Maintenance  class  can  be 
used  to  describe  medical  treatment. 
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The  degree  of  Entity  level  alignment  of  the  maintenance  class  is  the  average  of  the  de¬ 
grees  of  alignment  of  its  methods  (25%). 

A.2.7.i.TheconductMaintenance()  Method  (State  Level) 

The  conductMaintenanceO  method  aligns  to  the  AICDM  to  the  same  degree  as  does  the 
conductMaintenanceO  method  of  the  Unit  class  (25%).  See  Section  A.  1.1 0.1. 


A.2.8.  Crew  Class  (Entity  Level) 

The  Crew  class  models  the  persons  assigned  to  a  platform  as  its  crew.  Presumably  this 
platform  is  materiel,  not  a  person  or  facility,  and  the  crew  are  persons,  not  materiel  or  fa¬ 
cilities. 


Table  A- 18.  AICDM  entities  that  align  with  theCrew  class  at  the  Entity  level 


AICDM  Entity 

Suggested  By 
OMSC 
Method 

Relation  to  MATERIEL 

PERSON 

getQuantityO 

MATERIEL  has  associ ated  P E R S 0 N  entities. 

PERSON-TYPE 

getQuantityO 

MATERIEL  has  associated  PERSON-TYPE  entities. 

The  degree  of  Entity  level  alignment  of  the  Crew  class  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (100%). 


A.2.8.1. The getQuantityO  Method  (State  Level) 

There  is  perfect  State  level  alignment  (100%)  between  the  AICDM  and  the  OMSC  with 
respect  to  the  getQuantityO  method.  The  reasons  are  similar  to  those  for  the  getQtyOnHandO 
method  in  Section  A.  1.1 1.3.  That  method  had  a  high  degree  of  State  level  alignment.  The 
situations  where  it  was  imperfect  had  to  do  with  modeling  materiel  quantity.  The 
getQuantityO  method  always  models  people. 


Some  AICDM  attributes  have  values  that  suggest  crew.  MATERiEL-PERSQN  has  an  attrib-  [value 
ute  MATERiEL-PERSQN  TYPE  CQDE.  One  value  of  this  code  is  “is  assigned  to”.  Another  is 
“is  operated  by”.  If  it  is  necessary  to  only  record  the  relationship  between  a  specific  plat¬ 
form  and  the  number  of  its  crew,  then  the  HQLDiNG  estimate  could  be  used.  MATERiEL  has 
a  many-to-many  association  with  PERSQN-TYPE: 


•  MATERiEL  is  inventoried  by  PERSQN-TYPE-MATERiEL-HQLDiNG-ESTiMATE 


•  PERSQN-TYPE  maybe  included  in  MATERiEL-iTEM-MATERiEL-HQLDiNG-ESTiMATE 


A.2.9.  Communications  Class  (Entity  Level) 

The  Communications  class  is  identical  to  the  Communications  class  for  a  Unit  (see  Sec¬ 
tion  A.1.4),  except  that  changes  affect  relationships  between  the  MATERiEL  entity  model- 
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ing  the  platform  and  its  communications  network,  rather  than  between  an  ORGANIZATION 
entity  modeling  a  unit  and  its  communications  network.  The  Communications  class  of  the 
Platform  standard  object  aligns  to  the  AICDM  to  the  same  degree  as  the  Communications 
class  of  the  Unit  standard  object  (81%). 


A.2.10.  Carrier  Class  (Entity  Level) 

The  Carrier  class  models  the  ability  of  a  platform  to  carry  personnel  and  materiel.  This 
type  of  platform  is  MATERIEL,  not  a  PERSON  or  FACILITY.  Acarrier  cannot  carry  a  FACILITY. 

Table  A- 19  shows  the  AICDM  entities  that  model  carrying  these  things.  It  includes: 

•  AICDM  entities  that  can  represent  the  individual  personnel  and  materiel  carried  by  a 
platform. 

•  The  holdings  estimates  for  numbers  of  personnel  and  materiel  that  may  be  carried  by 
a  platform. 

•  The  occurrence  of  load  and  unload  activities,  which  can  be  recorded  via  the  AICDM 
ACTION  entity. 

The  value  for  the  activity  of  loading  or  unloading  materiel  or  persons  onto  a  platform  can 
be  modeled  via  the  ACTION-related  entities,  where  ACTION-OBJECTIVE-MATERIEL  could 
specify  the  platform  which  is  being  loaded  or  unloaded.  If  there  is  a  need  to  specify  which 
battlefield  object  must  carry  out  this  activity  then  the  ACTION-RESOURCE-ITEM  or  the 
ACTION-RESOURCE-TYPE  hierarchies  can  be  used  to  capture  that  aspect  of  loading  and 
unloading,  e.g.,  ACTION-RESOURCE-PERSON  or  ACTION-RESOURCE-ORGANIZATION,  Addi¬ 
tional  domain  values  may  be  required  for  the  ACTION-VERB  CODE  to  support  this  require¬ 
ment. 


Table  A- 19.  AICDM  entities  that  align  with  theCarrier  class  at  the  Entity  level 


AICDM  Entity 

Suggested  By  OMSC 
Method 

Relation  to  MATERIEL 

MATERIEL  (ground, 
water,  and  space) 

•  loadO 

•  unloadO 

MATERIEL  has  a  many-to-many  relationship 
to  MATERIEL  via  a  MATERIEL-ASSOCIATION. 

PERSON  (person) 

•  loadO 

•  unload!) 

MATERIEL  has  associated  PERSON  entities. 

MATERIEL-ITEM 

(ground,  water,  and 
space) 

•  loadO 

•  unload!) 

•  getRemainingCapacityO 

•  getTotalCapacityO 

•  getQtyOnHandO 

MATERIEL  has  associated  MATERIEL-ITEM  enti¬ 
ties;  the  association  estimates  the  number 
of  items  of  the  type. 

PERSON-TYPE  (per¬ 
son) 

•  loadO 

•  unload!) 

•  getRemainingCapacityO 

•  getTotaiCapacityO 

•  getQtyOnHandf) 

MATERIEL  has  associated  PERSON-TYPE  enti¬ 
ties;  the  association  estimates  the  number 
of  persons  of  the  type. 
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AICDM  Entity 

Suggested  By  OMSC 
Method 

Relation  to  MATERIEL 

•  ACTION 

•  ACTION-OBJECTIVE 
and  its  subtypes 

•  ACTION-RESOURCE 
and  its  subtypes 

•  loadO 

•  unload!) 

MATERIEL  is  specified  as  ACTION-OBj  ECTIVE- 
MATERIEL. 

MATERIEL  is  specified  as  ACTION-RESOURCE- 
MATERIEL. 

The  degree  of  Entity  level  alignment  of  the  Carrier  class  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (85%). 


A.2.io.i.The  loadO  Method  (State  Level) 


The  following  ambiguities  in  load()  (and  unloadO,  below)  limit  the  alignment  analysis: 

•  The  results  of  this  method  are  not  clear.  Consider  loading  personnel  onto  a  platform. 
Neither  Platform  nor  Carrier  has  any  associations  with  a  class  that  could  model  person¬ 
nel.  Perhaps  the  intent  of  this  method  is  to  model  loading  a  quantity  of  personnel  or 
materiel  onto  a  carrier,  rather  than  modeling  instances. 

This  is  a  behavioral  method.  After  it  is  invoked,  the  getRemainingCapacityO  method  should 
reflect  that  the  carrier’s  capacity  has  been  diminished  by  the  number  of  items  loaded. 

There  is  perfect  State  level  alignment  (100%)  between  the  AICDM  and  the  OMSC  with 
respect  to  the  load()  method.  Modeling  load()  in  the  AICDM  probably  (given  the  ambigu¬ 
ity)  means  creating  a  new  instance  of  MATEREL-ITEM-MATERIEL-HOLDING-ESTIMATE  or 
PERSON-TYPE-MATERIEL-HOLDING-ESTIMATE  and  associating  it  with  the  platform  through 
the  relationships  listed  in  Table  A-19. 


The  MATEREL-ITEM-MATERIEL-HOLDING-ESTIMATE  entity  has  several  attributes  whose  val¬ 
ues  can  probably  be  fixed  for  the  purposes  of  alignment 


Aaluh 


MATEREL-ITEM-MATERIEL-HOLDING-ESTIMATE  ACCURACY  EVALUATION  CODE  denotes  the 
accuracy  of  the  estimate.  For  a  simulation,  the  estimate  can  probably  be  considered 
accurate,  so  the  value  of  the  attribute  is  CONFIRMED. 


Value 


MATEREL-ITEM-MATERIEL-HOLDING-ESTIMATE  RELIABILITY  EVALUATION  CODE  denotes  the 
degree  of  reliability  of  the  estimate.  For  a  simulation,  the  estimate  can  probably  be 
considered  reliable,  so  the  value  of  the  attribute  is  COMPLETELY  RELIABLE. 


Value 


MATEREL-ITEM-MATERIEL-HOLDING-ESTIMATE  TYPE  CODE  characterizes  the  estimate. 
For  a  simulation,  its  value  can  be  ACTUAL. 


Value 


A.2.io.2.The  unloadO  Method  (State  Level) 

This  is  a  behavioral  method.  It  aligns  to  the  same  degree  that  the  load()  method  aligns. 
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A.2.io.3.ThegetRemainingCapacity()  Method  (State  Level) 

This  is  a  behavioral  method.  Its  effect  is  analogous  to,  and  its  degree  of  alignment  equiva¬ 
lent  to,  that  of  the  getRemainingCapacityO  method  of  the  Supply  class  (75%). 

A.2.io.4.ThegetTotalCapacity()  Method  (State  Level) 

This  is  a  behavioral  method.  Its  effect  is  analogous  to,  and  its  degree  of  alignment  equiva¬ 
lent  to,  that  of  the  getTotalCapacityO  method  of  the  Supply  class  (75%). 

A.2.io.5.ThegetQtyOnHand()  Method  (State  Level) 

This  method  aligns  indirectly  to  the  AICDM.  Its  degree  of  alignment  is  the  minimum  of 
the  degrees  of  alignment  of  getRemainingCapacityO  and  getTotalCapacityO,  from  which  its 
value  is  calculated  (75%). 

A.2.11.  PlatformFrameClass  (Entity  Level) 

The  PlatformFrame  class  contains  physical  models  of  a  platform.  The  OMSC  describes  a 
physical  model  as  follows: 

This  may  be  a  detailed  model,  but  typically  is  data  required  by  sensors  to  ac¬ 
quire/detect  the  platform.  Examples  of  the  physical  data  are  the  visual  signature, 
thermal  signature,  acoustic  signature  and  cross  sectional  area.  Platform  orienta¬ 
tion  and  other  descriptions  also  belong  here. 

The  AICDM  contains  descriptive  data  for  a  variety  of  physical  characteristics  of  plat¬ 
forms: 

•  The  E Q U IP  M  E  NT-TY P  E  entity  has  height,  length,  width,  volume,  and  weight  attributes. 

•  The  VEHICLE -TYPE  entity  has  height,  length,  and  width  attributes. 

•  The  PERSON  entity  has  height,  usual  weight,  hair  color,  and  eye  color  attributes. 

The  PlatformFrame  class  contains  physical  models  of  a  platform.  These  models  typically 
supply  data  required  by  sensors  to  detect  the  platform.  The  AICDM  does  not  generally 
contain  such  data.  The  exception  is  cross-sectional  area,  modeled  as  shown  in  Table 
A-20. 
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Table  A-20.AIC DM  entities  that  align  to  the  PlatformFranne  class  at  the  Entity 

levei 


AICDM  Entity 

Suggested  By 
OMSC  Method 

Relation  to  MATERIEL 

EQUIPMENT-TYPE  (ground, 
water,  and  space  plat¬ 
forms) 

getSignatureO 

MATERIEL  has  MATERIEL  entities,  for  associat¬ 
ing  instances,  and  associated  MATERIEL-ITEM 
entities,  for  associating  types.  MATERIEL- 
ITEM  identifies  EQUIPMENT-TYPE. 

VEHICLE-TYPE  (ground 
platforms) 

getSignatureO 

MATERIEL  has  MATERIEL  entities,  for  associat¬ 
ing  instances,  and  associated  MATERIEL-ITEM 
entities,  for  associating  types.  MATERIEL- 
ITEM  identifies  VEHICLE-TYPE. 

PERSON  (person  plat¬ 
forms) 

getSignatureO 

PERSON  has  MATERIEL  entities,  for  associat¬ 
ing  instances,  and  associated  MATERIEL-ITEM 
entities,  for  associating  types.  MATERIEL- 
ITEM  identifies  EQUIPMENT-TYPE. 

The  degree  of  Entity  level  alignment  of  the  PlatformFrame  class  is  the  average  of  the  de¬ 
grees  of  alignment  of  its  methods  (25%). 


A.2.ii.i.ThegetSignature()  Method  (State  Level) 

There  is  a  low  degree  of  State  level  alignment  (25%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  getSignature()  method.  Of  the  example  signatures  given,  the 
AICDM  can  accommodate  only  a  few,  including  weight  and  dimensions. 


A.2.12.  FrameComponent  Class  (Entity  Level) 


A  FrameComponent  provides  for  hierarchical  structuring  of  a  platform.  Table  A-21  shows 
the  AICDM  entities  that  provide  this  type  of  structuring.  The  sole  method  in  the  class 
provides  for  a  signature,  just  as  in  the  previous  section. 


Table  A-21.  AICDM  entities  that  align  to  the  FrameComponent  class  at  the  Entity 

level 


AICDM  Entity 

Suggested  By 
OMSC 
Method 

Relation  to  MATERIEL 

MATERIEL 

getSignatureO 

N/A 

MATERIEL- 

ASSOCIATION 

getSignatureO 

MATERIEL  uses  MATERIEL-ASSOCIATION  to  achieve  struc¬ 
ture. 

One  value  for  the  MATERIEL-ORGANIZATION  TYPE  CODE  attribute  is  IS  A  COMPONENT  OF.  |value 
This  seems  to  capture  the  intent  of  the  FrameComponent  relationships. 


The  degree  of  Entity  level  alignment  of  the  FrameComponent  class  is  the  average  of  the  de¬ 
grees  of  alignment  of  its  methods  (25%). 
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A.2.i2.i.ThegetSignature()  Method  (State  Level) 

The  getSignatureO  method  aligns  to  the  AICDM  to  the  same  degree  as  the  getSignatureO 
method  of  the  PlatformFrame  class  (25%).  See  Section  A.2. 11.1. 

A.3  Location  Standard  Object  (Conceptual  Level) 

The  Location  standard  object  is  defined  in  a  technical  report  dated  October  1998 
[JHB  1998].  The  report  is  designated  as  not  completed. 

An  OMSC  location  is  “typically”  a  point.  The  OMSC’s  Unit  standard  object  has  a  method 
Unite eometry.getShapeO.  We  infer  from  this  that  a  location  is  not  a  shape,  and  therefore  de¬ 
fine  a  conceptual  level  view  for  the  AICDM  that  models  only  points,  not  geometric  fig¬ 
ures. 

The  Location  class  is  the  focal  class  of  the  Location  standard  object. 

POiNT  is  the  focal  entity  of  the  AICDM  view  for  a  location. 


Table  A-22.  AICDM  entities  that  align  with  classes  of  the  Location  standard  object 

at  the  Conceptual  level 


OMSC  Class 

Related  AICDM  Entity 

Relation  to  POINT 

Geocentric 

POINT 

Identical  (the  same  entity) 

Geocentric 

MEASURED-ELEVATION-POINT 

MEASURED-ELEVATION-POINT  Is  a  subtype 
of  POINT.  See  Figure  A-2. 

The  degree  of  Conceptual  level  alignment  of  the  Location  standard  object  is  the  average  of 
the  degrees  of  alignment  of  its  classes  (37%). 


A.3.1.  Location  Class  (Entity  Level) 

The  Location  class  does  not  directly  align  with  any  AICDM  classes.  The  reason  is  that  it  is 
a  superclass,  and  AICDM  entities  related  to  location  do  not  use  a  corresponding  super¬ 
class  model.  However,  subclasses  of  Location  align  to  AICDM  entities. 

The  method  names  in  Location  do  not  indicate  a  need  for  any  other  AICDM  entities. 

The  degree  of  Entity  level  alignment  of  the  Location  class  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (37%). 

A.3.i.i.ThedistanceFrom()  Method  (State  Level) 

The  distanceFromO  method  calculates  the  distance  from  one  point  to  another.  It  is  either  a 
class  method  requiring  two  parameters — ^both  Location  instances — or  an  instance  method 
requiring  one  parameter,  and  using  the  invoking  instance  as  the  second  point.  It  returns  a 
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non-negative  value  representing  the  distance  between  the  two  locations.  The  units  of  the 
distance  are  unspecified. 

There  is  a  low  degree  of  State  level  alignment  (25%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  distanceFromO  method.  The  AICDM  can  model  only  geodetic 
locations  and  does  not  model  distances. 

A.3.i.2.The  convertO  Method  (State  Level) 

The  convertO  method  converts  points  from  one  coordinate  system  to  another.  It  is  either  a 
class  method  requiring  one  parameter — a  Location  instance — or  an  instance  method  using 
the  invoking  instance  as  the  point.  It  returns  a  value  in  the  opposite  coordinate  system.  (If 
the  OMSC  ever  adds  more  subclasses  of  Location,  convert!)  will  need  a  different  parameter 
schema. 

There  is  a  medium  degree  of  State  level  alignment  (50%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  convert!)  method.  The  AICDM  can  model  only  geodetic  dis¬ 
tances.  The  AICDM  provides  for  conversion  between  coordinate  systems  (actually,  be¬ 
tween  any  two  units  of  measure)  through  the  MEASURE-UNiT-CONVERSiON  entity.  Its 
MEASURE-UNiT-COVERSiON  ALGORiTHM  TEXT  attribute  provides  text  of  an  algorithm  to  con¬ 
vert  from  one  MEASURE-UNiT  to  another.  However,  the  attribute  is  free  text,  not  a  formal 
mapping  (see  Figure  A-22). 

A.3.2.  Local  Class  (Entity  Level) 

The  Locai  class  models  coordinates  expressed  in  a  local  (Cartesian)  coordinate  system. 

The  AICDM  does  not  model  locations  as  Cartesian  coordinates.  The  AICDM  and  the 
OMSC  do  not  align  with  respect  to  the  Local  class  at  the  Entity  level." 

The  degree  of  Entity  level  alignment  of  the  Local  class  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (0%). 

A.3.2.i.ThegetXCoordinate()  Method  (State  Level) 

There  is  no  State  level  alignment  (0%)  between  the  AICDM  and  the  OMSC  with  re¬ 
spect  to  the  getXCoordInate!)  method  . 


"  The  Army  has  developed  structures  for  international  operations  that  provide  for  this  type  of  specifica¬ 
tion.  The  ADMG  at  Ft.  Belvoir  is  considering  including  them  in  future  versions  of  the  AICDM. 
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A.3.2.2.ThegetYCoordiante()  Method  (State  Level) 

There  is  no  State  level  alignment  (0%)  between  the  AICDM  and  the  OMSC  with  respect 
to  the  getYCoordinateO  method  . 

A.3.2.3.ThegetZCoordinate()  Method  (State  Level) 

There  is  no  State  level  alignment  (0%)  between  the  AICDM  and  the  OMSC  with  respect 
to  the  getZCoordinateO  method. 

A.3.3.  LatLon  Class  (Entity  Level) 

The  Geocentric  class  models  coordinates  expressed  in  a  geodetic  coordinate  system.  Table 
A-22  shows  the  AICDM  entities  that  map  to  OMSC  classes. 

The  degree  of  Entity  level  alignment  of  the  LatLon  class  is  the  average  of  the  degrees  of 
alignment  of  its  methods  (75%). 

A.3.3.i.ThegetLatitude()  Method  (State  Level) 

There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  getLatitudeO  method.  The  value  returned  by  the  getLatitudeO 
method  aligns  with  three  AICDM  attributes  of  POINT  (see  Figure  A-I4): 

•  The  POINT  LATITUDE  COORDINATE  attribute,  which  represents  the  actual  latitude. 

•  The  HORIZONTAL  REFERENCE  DATUM  CODE  attribute,  which  provides  a  reference  sys¬ 
tem  for  interpreting  the  latitude.  (Presumably  the  value  of  this  attribute  would  be  con¬ 
stant  for  all  latitudes  in  a  given  M&S  system.) 

•  The  POINT  HORIZONTAL  PRECISION  OUANTITY  attribute,  which  specifies  the  precision  of 
the  latitude. 

The  value  returned  by  getLatitudeO  is  in  seconds.  There  is  no  explicit  discussion  in  the 
AICDM  of  the  precision  of  POINT  LATITUDE  COORDINATE.  However,  the  AICDM  is  based 
on  WGS  84,  which  states  that  positions  shall  be  reported  precise  to  tenths  of  a  second 
[SNF].  Therefore,  getLatitudeO  and  POINT  LATITUDE  COORDINATE  do  not  align  perfectly. 

A.3.3.2.ThegetLongitude()  Method  (State  Level) 

There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  getLongItudeO  method.  The  value  returned  by  the  getLongItudeO 
method  aligns  with  three  AICDM  attributes  of  POINT  (see  Figure  A-I4): 

•  The  POINT  LONGITUDE  COORDINATE  attribute,  which  represents  the  actual  latitude. 
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•  The  HORIZONTAL  REFERENCE  DATUM  CODE  attribute,  which  provides  a  reference  sys¬ 
tem  for  interpreting  the  latitude.  (Presumably  the  value  of  this  attribute  would  be  con¬ 
stant  for  all  latitudes  in  a  given  M&S  system.) 

•  The  POINT  HORIZONTAL  PRECISION  OUANTITY  attribute,  which  specifies  the  precision  of 
the  latitude. 

Two  assumptions  about  OMSC  latitudes  and  longitudes  are  necessary  for  alignment  be¬ 
tween  the  two  models: 

•  Latitudes  and  longitudes  are  specified  using  the  same  horizontal  reference. 

•  Latitudes  and  longitudes  are  specified  using  the  same  precision. 

Both  these  assumptions  seem  highly  probable. 

The  value  returned  by  getLongltudeO  is  in  seconds.  There  is  no  explicit  discussion  in  the 
AICDM  of  the  precision  of  POINT  LONGITUDE  COORDINATE.  However,  the  AICDM  is 
based  on  WGS  84,  which  states  that  positions  shall  be  reported  precise  to  tenths  of  a  sec¬ 
ond  [SNF].  Therefore,  getLongltudeO  and  POINT  LONGITUDE  COORDINATE  do  not  align  per¬ 
fectly. 

A.3.3.3.ThegetAltitude()  Method  (State  Level) 

There  is  a  high  degree  of  State  level  alignment  (75%)  between  the  AICDM  and  the 
OMSC  with  respect  to  the  getAltItudeO  method.  The  value  returned  by  the  getAltItudeO 
method  aligns  with  the  following  attributes  of  MEASURED-ELEVATION-POINT  (see  Figure 
A-14): 

•  MEASURED-ELEVATION-POINT  ELEVATION  DIMENSION,  which  specifies  the  elevation. 

•  MEASURED-ELEVATION-POINT  PRECISION  OUANTITY,  which  specifies  the  precision  of  the 
elevation. 

•  MEASURED-ELEVATION-POINT  TYPE  CODE,  which  provides  a  reference  system  for  inter¬ 
preting  the  elevation. 

The  value  returned  by  getAltItudeO  is  in  feet.  MEASURED-ELEVATION-POINT  ELEVATION 
DIMENSION  is  in  meters.  An  automated  translation  system  would  need  to  be  implemented 
to  achieve  perfect  alignment. 
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Appendix  B. 

A  Critique  of  the  OMSC  Object  Modei 


This  appendix  provides  a  brief  critique  of  the  design  of  objects  in  the  OMSC  Object 
Model.  The  OMSC  Object  Model  is  to  serve  as  a  framework  for  designing  and  develop¬ 
ing  simulation  software.  The  developers  hope  that  the  model  will  lead  to  a  repository  of 
reusable  software  that  can  reduce  the  cost  and  time  required  to  develop  future  simulation 
systems. 

Achieving  this  laudable  objective  could  have  wide-ranging  impact  on  Army  programs. 
However,  the  model  will  yield  good  designs  and  reusable  software  if  the  objects  in  it  are 
themselves  well  designed  and  implemented.  A  thorough  critique  of  the  model  is  therefore 
imperative. 

The  alignment  analysis  has  uncovered  several  potential  problems  with  the  OMSC  Object 
Model.  Some  of  these  problems  are  problems  only  insofar  as  alignment  with  C4I  systems 
is  concerned.  The  OMSC  object  model’s  developers  did  not  consider  alignment,  so  the 
OMSC  obviously  cannot  be  faulted  for  alignment  flaws.  These  problems  are  mentioned 
for  the  sake  of  future  M&S  modeling  efforts,  whether  the  OMSC  object  model  or  some 
other  model.  Modelers  will  want  to  avoid  design  decisions  that  will  hinder  alignment. 

Other  problems  in  the  OMSC  object  model  are  independent  of  alignment.  The  OMSC 
standard  objects  were  developed  by  studying  legacy  systems,  and  the  problems  in  this 
category  may  reflect  flaws  in  the  design  of  those  systems.  Avoiding  these  types  of  prob¬ 
lems  should  promote  ease  of  design,  interoperability,  and  software  reuse  among  M&S 
systems. 

Briefly,  the  problems  are  as  follows: 

•  The  standard  definitions  have  too  many  ambiguities  to  be  useful. 

•  Some  of  the  so-called  objects  are  not  really  objects,  but  are  instead  encapsulations  of 
related  functions. 

•  The  relationships  between  objects  are  not  properly  captured. 

This  appendix  presents  each  problem,  using  examples  drawn  from  the  definitions  of  the 
Unit  and  Platform  standard  objects.  It  discusses  why  these  problems  are  likely  to  impede 
the  utility  of  OMSC  objects.  It  suggests  fixes  for  the  problems. 
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This  appendix  concentrates  on  problems  inherent  in  the  high-level  design  decisions  that 
went  into  creating  the  OMSC.  It  omits  low-level  details  that  relate  to  alignment.  Section  7 
gives  these  details. 

It  must  be  noted  that  the  OMSC’s  creators  regard  the  issues  identified  in  this  appendix 
not  as  problems  but  as  appropriate  design  decisions  in  response  to  the  OMSC’s  charter, 
which  states  that  the  standard  objects,  and  the  classes  they  contain,  are  to  be  simulation- 
independent.  They  took  care  to  create  “no  specifications  that  would  impact  or  direct  im¬ 
plementation”  [H  2000].  They  believe  that  many  of  the  recommendations  in  this  appen¬ 
dix,  as  well  as  in  Section  7,  violate  their  charter. 

Abstraction  is  a  powerful  tool  for  system  design  and  reuse,  but  by  definition  an  increase 
in  abstraction  yields  some  decrease  in  utility.  The  IDA  study  team  believes  that,  if  the 
OMSC  is  to  promote  interoperability  and  reuse,  the  standards  it  establishes  must  be  more 
concrete  than  their  current  form.  Time  and  experience  will  of  course  be  the  ultimate  arbi¬ 
ters  of  whether  the  OMSC  standard  objects  are  appropriate. 

B.l  Object  Descriptions  Have  Ambiguities 

The  OMSC  model  is  divided  into  a  set  of  standard  objects.  Each  standard  object,  such  as 
Unit  or  Platform,  is  described  in  a  single  document.  Each  standard  object  is  specified  as  a 
set  of  classes.  One  of  these  classes  provides  the  definition  for  the  object  that  is  the  focus 
of  the  document.  The  other  classes  are  associated  with  the  main  object  using  inheritance 
or  aggregation  relationships.  These  relationships  are  shown  in  a  picture. 

Each  class  is  specified  using  a  textual  definition  and  a  set  of  public  methods.  Each  public 
method  is  in  turn  specified  using  a  textual  definition  that  describes  its  effect.  For  exam¬ 
ple,  the  Unit  class  is  defined  using  the  text: 

Class  Unit:  A  “Unit”  is  any  military  organization  that  is  composed  of  multiple 
entities.  Examples  include  military  organizations  such  as  a  company,  battalion, 
brigade,  or  division. 

The  Unit  class  has  ten  public  methods,  one  of  which  is  getVelocityO.  The  definition  of 
getVelocityO  is: 

getVelocityO:  Returns  the  current  velocity  (direction  of  movement  and  rate)  of  the 
unit. 

This  is  the  extent  of  the  specification.  Details  have  deliberately  been  omitted,  because  the 
OMSC’s  designers  feel  that  including  them  would  constrain  implementations.  However, 
the  missing  details  leave  too  much  room  for  interpretation.  An  implementation  is  likely  to 
contain  objects  that  are  application-specific.  The  following  sections  list  ambiguities  in  the 
specifications  of  objects. 

It  is  worth  noting  that  many  of  the  ambiguities  could  be  eliminated  by  the  adoption  of 
more  careful  documentation  standards.  For  example,  following  the  style  that  Sun  Micro- 
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systems  uses  to  describe  Java  classes  would  of  necessity  clarify  many  of  the  issues  de¬ 
scribed  below. 


Unknown  Parameter  Specifications 


None  of  the  methods  list  any  parameters.  For  example,  the  UnitmoveO  method  advances  a 
unit  towards  its  next  location.  The  method’s  description  does  not  indicate  how  a  devel¬ 
oper  specifies  the  next  location.  Any  of  the  following  are  possible: 


move(x,  y:  float) 

move(x:  latitude;  y:  longitude) 

move(l:  Location) 

move( orientation:  float,  distance: 
float) 


Coordinate  pair,  Cartesian  model 
Coordinate  pair,  geodetic  model 
Coordinates  using  Location  standard  object 
New  location  is  relative  to  current  location 


These  and  other  possible  parameters  (e.g.,  the  amount  of  time  taken  for  the  move,  or  the 
route  taken  for  the  move)  are  left  to  the  developer’s  imagination. 

In  a  reuse  library,  the  implementations  of  methods  would  of  course  have  parameter 
schema  specified.  However,  unless  the  designers  of  the  OMSC  act  now  to  state  their  in¬ 
tent  as  to  (for  instance)  how  one  specifies  movement,  a  library  resulting  from  the  specifi¬ 
cations  is  likely  to  consist  of  a  collection  of  operations  that  apply  only  to  the  application 
for  which  they  are  developed. 


B.1.2.  Unknown  Return  Values 

This  issue  is  similar  to  unknown  parameter  specifications.  The  methods  do  not  indicate 
the  type  of  values  they  return.  Often  the  reader  cannot  infer  if  a  method  returns  a  string  or 
an  object  instance  For  instance,  the  UnitgetSideO  method  returns  “the  faction  or  coalition 
for  the  platform’’.  This  can  be  interpreted  as  either  of  the  following: 

•  getSideO:  String 

•  gets ide():  Organization 

There  is  an  extra  benefit  to  stating  return  types,  ft  forces  some  thought  about  additional 
classes  (such  as  Organization)  that  the  OMSC  might  need.  Consideration  of  these  classes 
would  increase  the  OMSC’s  completeness. 

B.1.3.  Unknown  Units 

The  units  in  which  numeric  values  are  stated  is  never  given.  The  story  of  the  Mars  Cli¬ 
mate  Orbiter,  which  crashed  on  the  surface  of  Mars  because  an  English/Metric  inconsis- 
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tency  put  it  in  an  orbit  too  close  to  the  planet’s  surface,  should  underscore  the  importance 
of  defining  units  up  front. 


B.1.4.  Unknown  Constructors  and  Modifiers 

The  descriptions  never  provide  a  class  constructor,  nor  do  they  explicitly  specify  instance 
modifiers  (“setT”  methods).  This  means  that  the  complete  set  of  attributes  expected  of  an 
instance  for  the  purposes  of  simulation  cannot  be  determined.  The  following  constructor 
for  Unit: 

Unit(id:  String,  I:  Location) 

indicates  that  a  unit  must  always  have  an  ID  and  a  location. 

B.2  Ciass  Design  Is  Not  Based  on  Objects 

The  design  of  the  model  suggests  that  some  classes  were  created  to  package  related  func¬ 
tions.  There  is  nothing  wrong  with  packaging  functions  into  a  class,  but  other  parts  of  the 
model  seem  to  imply  that  these  packages  are  to  be  treated  as  collections  of  objects.  An 
object,  according  to  the  usual  definition,  has  a  current  state.  A  collection  of  functions 
does  not  have  a  state. 

All  the  component  classes  of  Unit  (Communications,  UnitGeometry,  Intel,  SystemGroup,  Attrition, 
Logistics,  and  C2)  are  packages  of  related  functions  rather  than  classes  of  objects.  The 
Platform  class  has  two  component  classes.  Sensor  and  Weapon,  that  from  their  descriptions 
seem  like  classes  of  objects.  The  other  classes  (Movement,  Logistics,  Crew,  Communications, 
Carrier,  and  PlatformFrame)  appear  to  be  packages  of  related  functions. 

Aggregating  related  functions  is  a  valid  design  practice.  However,  the  practice  is  unlikely 
to  yield  significant  software  reuse  when  compared  to  a  design  based  on  objects.  In  any 
event,  some  analysis  of  the  model  reveals  opportunities  for  an  improved  object-oriented 
design.  The  rest  of  this  section  makes  some  suggestions  in  that  regard. 

B.2.1.  UnitGeometry 

The  UnitGeometry  class  has  two  methods:  getShapeO  and  getOrlentatlon(). 

This  class’  name  suggests  that  it  models  only  the  geometry  of  units.  Other  OMSC  entities 
require  geometry,  too.  For  instance,  platforms  have  a  cross-sectional  area  signature  that  is 
used  by  sensors. 

Therefore,  it  would  be  better  to  replace  UnitGeometry  with  a  class  named  Geometry,  which 
can  model  the  geometry  of  any  entity.  Geometry  should  be  a  virtual  class.  It  should  have 
subclasses  for  various  types  of  shapes,  such  as  (for  two  dimensions)  rectangle  and  circle. 
See  Figure  B-1. 
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Figure  B-1.  Geometry  Class  Hierarchy 

Note  that  this  hierarchy  does  not  have  a  getShapeO  or  getOrientationO  method.  Geometry  and 
its  subclasses  model  the  concept  of  geometry.  The  getShapeO  and  getOrientationO  methods 
belong  in  the  Unit  class,  declared  as  follows: 

•  getShapeO:  Geometry 

•  getOrientationO:  fioat 


B.2.2.  Communications 

This  class  seems  too  atomic.  The  descriptions  of  the  methods  suggest  the  existence  of 
Messages,  Nodes,  and  Networks  as  primitive  elements  that  make  up  the  ability  to  com¬ 
municate.  The  OMSC  should  have  Message,  Node,  and  Network  classes. 


B .2.3.  SystemG roup 

The  methods  of  this  class  indicate  that  it  is  a  placeholder  for  component  systems  or  plat¬ 
forms  associated  with  the  unit.  The  methods  can  all  be  eliminated,  and  replaced  by  invo¬ 
cations  of  methods  in  the  parent  unit.  That  is, 

u.sg.acceptGains(l) 

is  equivalent  to: 

u.addSystem(s) 

This  has  the  added  advantage  of  explicitly  associating  a  system  instance  with  a  unit, 
rather  than  just  incrementing  the  number  of  systems  of  some  type.  Simulating  the  func¬ 
tionality  of  acceptGainsO  would  of  course  present  no  challenge. 
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B. 2.4.  Attrition 


The  definition  of  the  class  reads  as  follows: 

The  attrition  component  allows  the  unit  to  cause  losses  to  another  unit. 

The  capability  of  unit  A  to  cause  losses  to  unit  B  is  not  a  component  of  the  unit.  It  is  a 
computable  quantity  based  on  unit  As  current  fire  systems  capability  (or  whatever  de¬ 
structive  capability  A  might  possess). 

Modeling  attrition  therefore  requires  knowing  how  much  destructive  capability  one  unit 
aims  at  another.  It  is  this  factor  that  should  be  encapsulated.  The  causeAttritionO  function 
should  be  packaged  but  need  not  otherwise  be  part  of  a  class  associated  with  U  nit. 

B.2.5.  Logistics 

The  description  of  the  Logistics  class  indicates  that  it  is: 

intended  to  capture  or  represent  the  internal  logistics  capability  and/or  require¬ 
ments  of  the  unit. 

This  description  is  at  odds  with  Logistics. received,  which  is  “used  to  increment  the  quantity 
of  this  logistic  component.”  Incrementing  a  quantity  does  not  capture  capability. 

In  any  event,  capturing  requirements  does  not  imply  the  need  for  an  object  instance.  It 
rather  describes  a  set  of  attributes  that  could  just  as  easily  be  part  of  the  Unit  class. 

As  for  incrementing  (or  decrementing)  quantity  of  a  logistics  component,  the  component 
can  be  part  of  a  Unit.  See  Section  B.2.3. 

B.3  Inter-Class  Relationships  Do  Not  Foiiow  a  Consistent 
Modei 

The  OMSC  Platform  and  Unit  documents  show  a  design  of  each  object  as  a  picture.  This 
picture  contains  classes,  and  two  types  of  inter-class  relationships:  inheritance  and  aggre¬ 
gation. 

The  inheritance  relationships  are  not  stated  according  to  usual  modeling  conventions. 
They  show  a  label  of  “0+”  (figures  in  this  document  are  modifications  of  those  in  OMSC 
documents).  This  label  is  meaningful  in  an  aggregation  relationship,  but  not  in  an  inheri¬ 
tance  hierarchy.  The  labels  should  be  removed  from  inheritance  relationships. 

The  aggregation  relationships  all  have  “0+”  labels.  In  an  object  model,  this  label  indicates 
a  relationship  between  a  parent  and  a  child;  it  means  that  zero  or  more  instances  of  the 
child  are  associated  with  the  parent. 

However,  because  most  of  the  classes  other  than  Unit  and  Platform  are  packages  of  func¬ 
tions  rather  than  collections  of  objects,  a  0+  relationship  has  no  meaning.  For  example. 
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the  Platform  object  has  a  0+  relationship  with  the  Movement  object.  Movement  is  a  col¬ 
lection  of  3  functions  (getVelocityO,  changeVelocityO,  and  moveToO)  with  no  obvious  underly¬ 
ing  object  being  part  of  the  class.  Obviously  the  relationship  does  not  mean  that  there  are 
different  instances  of  each  function  that  might  be  invoked.  How,  then,  should  it  be  inter¬ 
preted? 

Most  likely,  the  relationship  indicates  packaging  and  not  aggregation.  The  diagram  nota¬ 
tion  needs  to  be  extended  to  capture  this  new  relationship. 
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Appendix  C.AIC DM  Views  and  Their  Status 


This  appendix  lists  the  views  in  the  current  version  of  the  AICDM.  These  views  give  a 
flavor  of  the  AICDM’s  intent:  to  model  battlefield  objects.  The  AICDM  attempts  to 
model  anything  that  might  be  relevant  to  the  warfighter.  Personnel,  materiel,  organiza¬ 
tions,  terrain,  and  organizations  are  all  within  its  purview. 

Table  C-1  lists  the  views,  in  alphabetical  order.  The  following  is  an  explanation  of  the 
entries  in  the  Status  column: 

•  To  be  worked:  It  is  recognized  that  work  needs  to  be  performed  on  the  view.  How¬ 
ever,  there  is  no  timetable  for  performing  the  work. 

•  Working:  It  is  recognized  that  work  needs  to  be  performed  on  the  view.  Work  is  ongo¬ 
ing,  and  there  is  a  timetable  for  performing  the  work. 

•  Package:  Submitting  a  view  for  changes  and  revisions  in  accordance  with  DoD- 
8320.1-M-l  requires  preparing  a  data  proposal  package  containing,  among  other 
things,  an  ERWin  model  of  the  data  together  with  metadata  specifications.  This  status 
means  the  package  has  been  created  and  is  ready  to  be  released  for  cross-functional 
review  and  eventual  approval. 

•  To  be  Updated:  After  a  data  proposal  package  has  been  submitted,  experts  generally 
make  comments.  If  the  resolution  of  these  comments  requires  further  changes  to  a 
view,  that  view’s  status  is  “to  be  updated”  until  the  changes  are  made. 

•  Approved:  The  updates  are  finished. 


Table  C-1.  AICDM  Views  and  Their  Status 


View 

Status 

ACTION 

Approved 

Action-Resource-Employment  View 

To  be  worked 

CANDIDATE-TARGET 

Approved 

CAPABILITY 

Approved 

DETAI LS  Task  Action  View 

To  be  worked 

DETAILS  ski ll/pos/occ-2  View 

To  be  worked 

Enemy  Org  View 

To  be  worked 

Establishment 

Package 

Feature  View 

Approved 

Force  Package  Type  view 

To  be  worked 
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View 

Status 

Graphic 

Package 

Holding  View 

Package 

1  nformation  Reference 

Package 

LOCATION 

Working 

MATERIEL  item  and  type  View 

To  be  worked 

ORGANIZATION 

Approved 

ORGANIZATION -TYPE 

Approved 

Operational  Specialty  View 

To  be  worked 

Plan  View 

Approved 

Task  View 

To  be  worked 

Version  1  Full  Model 

To  be  worked 

mat- item  View 

To  be  worked 

met  View 

To  be  worked 

met-feature  View 

To  be  worked 

ski  ll/pos/occ  View 

To  be  worked 

standards  compliant  full  model  view 

To  be  up¬ 
dated 

ujtl  View 

To  be  worked 
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Appendix  D.  Specific  Recommended  Changes 


This  appendix  splits  the  specific  recommendations  from  Section  7  into  separate  tables, 
one  for  each  OMSC  standard  object.  The  intent  is  to  present  recommendations  catego¬ 
rized  by  OMSC  classes  and  methods. 


D.l  Unit  Standard  Object 


Unit  Class 


ThegetLocationO  Method 

Issues 

•  The  OMSC  is  ambiguous  about  how  a  unit  location  is  modeled.  It  says: 

Typically  [current  unit  location]  isthe center  of  mass  or  some 
other  point  location  representativeof  the  unit  location. 

1  f  center  of  mass  is  typical,  there  must  be  some  atypical  representations. 

The  OMSC  does  not  enumerate  them. 

•  The  OMSC  does  not  define  how  center  of  mass  is  computed.  M&S 
applications  use  different  models  that  depend  upon  factors  such  as  level  of 
aggregation  (corps/division  vs.  theater)  and  whether  the  simulation  is  for 
training  or  analytical  purposes.  (1  n  some  M&S  training  applications, 
center  of  mass  is  not  computed  at  all,  but  is  estimated  by  (and  entered  by) 
a  human  operator.) 

Recommended 
Changes  to  the 
OMSC 

•  The  OMSC  should  enumerate  all  valid  ways  in  which  a  unit's  location  can 
be  modeled.  A  better  approach  would  be  to  accept  center  of  mass  as  the 
standard  way  to  represent  location.  Other  location-like  quantities  (e.g., 
areas)  should  be  represented  using  other  classes. 

•  The  Location  class  should  have  a  virtual  method  centerOfMassO.  An  M&S 
application  based  on  theOMSC  would  need  to  supply  a  definition  for  the 
method. 

ThegetVelocityO  M 

ethod 

Issues 

•  The  AlCDM  does  not  model  velocity. 

•  The  OM  SC's  description  does  not  presai  be  the  units  in  which  velocity 
components  are  expressed. 

Recommended 
Changes  to  the 
AlCDM 

The  AlCDM  needs  to  beableto  model  the  velocity  of  (at  least)  thePERSON, 
MATERIEL,  and  ORGANIZATION  entities. 

Recommended 
Changes  to  the 
OMSC 

TheOMSC  should  define  a  (parameterized)  model  of  velocity.  The  model 
must  describe  units  and  degree  of  precision  (or  these  quantities  must  be 
parameters). 
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ThegetIDO  Method 

Issues 

The  OMSC  does  not  indicate  how  the  1 D  might  be  used.  Use  can  prescribe 
format.  (E.g.,  if  an  1 D  labels  units  on  a  screen,  it  must  be  short.)  This  in¬ 
fluences  whether  the  AlCDM  can  model  OMSC  1  Ds  using  existing  attrib¬ 
utes. 

Recommended 
Changes  to  the 
OMSC 

The  OMSC  should  define  a  model  of  1  Ds  based  on  their  use  in  existing 

M S(S  systems.  1  deal ly,  the  OM SC  should  use C4I  1  Ds. 

ThegetSideO  Method 

Issues 

•  The  OMSC  does  not  indicate  the  maximum  number  of  sides  that  must  be 
supported.  At  onetime  it  was  assumed  that  the  only  sides  would  be 
"blue"  and  "red",  but  with  the  advent  of  coalition  warfare  the  number  of 
possible  sides  has  grown.  Note  that  WARSI M  has  a  contractual 
requirement  to  support  at  least  36  different  sides. 

•  The  OMSC  states  that  there  is  no  implied  enmity  between  sides,  but  does 
not  state  the  possible  relationships  between  sides. 

•  The  AlCDM  does  not  have  an  explicit  model  of  sides,  although  one  can  be 
simulated  using  ORGANIZATION  structures. 

Recommended 
Changes  to  the 
AlCDM 

The  AlCDM  should  enhance  its  ability  to  model  friends  and  foes.  One  ap¬ 
proach  is  to  add  values  FACTION  and  COALITION  to  the  IDENTIFICATION- 
FRIEND-FOE  CODE  attributeof  theORGANIZATION  entity.  Another  is  to  ex¬ 
ternalize  the  FRIEND-FOE  attributes. 

Recommended 
Changes  to  the 
OMSC 

•  The  OMSC  should  state  explicitly  whether  there  is  an  implied  maximum 
number  of  sides. 

•  The  OMSC  should  enumerate  the  possible  relationships  between  sides. 

ThegetPostureO  Mi 

ethod 

Issues 

•  The  OMSC  does  not  enumerate  all  possible  postures. 

•  The  OMSC  does  not  relate  postures  to  other  objects.  For  instance,  a 
posture  such  as  "hasty  defense"  implies  that  a  unit's  velocity  is  zero. 

•  The  AlCDM  has  a  limited  set  of  attributes  that  can  represent  posture. 
Their  values  do  not  cover  the  examples  of  status  given  in  the  OMSC. 

Recommended 
Changes  to  the 
AlCDM 

The  AlCDM  needs  to  add  an  attribute  associated  with  an  ORGANIZATION 
that  can  represent  posture.  Si  nee  different  types  of  organizations  can  have 
different  types  of  posture  (e.g.,  a  civilian  organization  will  not  havethe 
same  types  of  a  posture  asa  military  organization),  it  might  makesenseto 
have  multi  pie  posture  attributes,  each  associated  with  a  subtype  of 
ORGANIZATION. 

Recommended 
Changes  to  the 
OMSC 

•  The  OMSC  needs  to  clarify  the  role  that  postures  play  in  simulations 
and  the  possible  values  they  may  have.  Do  they  need  to  be  distinguished 
from  current  activities,  as  elaborated  by  the  current  activity  codes  of  the 
ORGANIZATION  and  MILITARY-UNIT  entities? 

•  Whatever  a  posture  may  be,  the  set  of  valid  postures  for  a  given  M&S 
system  can  apparently  be  expressed  as  an  enumeration.  This  suggests 
what  the  result  of  u.getPostureO  should  be. 

ThegetStatusO  Method 
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Issues 

•  The  OM  SC  does  not  enumerate  the  different  types  of  status. 

•  The  AlCDM  has  a  very  limited  set  of  attributes  that  can  represent  status. 
Their  values  do  not  cover  the  examples  of  status  given  in  the  OMSC. 

Recommended 
Changes  to  the 
AlCDM 

Necessary  changes  to  the  AlCDM  cannot  be  determined  until  the  concept  of 
status  in  M&S  systems  is  better  understood.  However,  it  is  likely  that: 

•  TheAlCDM  will  need  to  accommodate  numeric  descriptions  of  status 
(e.g.,  as  percent  effectiveness). 

•  TheAlCDM  will  need  additional  codes. 

Recommended 
Changes  to  the 
OMSC 

The  OMSC  should  define  a  virtual  dassStatus.  Subclassesof  Status  would 
exist  for  every  entity  that  needs  to  record  status.  Subclass  methods  would 
record  and  provide  different  facets  of  status  as  appropri  ate  to  the  entity. 

ThegetMissionO  Method 

Issues 

The  OMSC  gives  no  structure  to  a  mission  or  task.  A  mission  is  only  free 
text.  TheAlCDM,  by  contrast,  has  a  rich  structure  that  the  OMSC  cannot 
model. 

Recommended 
Changes  to  the 
OMSC 

the  OMSC  should  define  a  Mission  standard  object  that  provides  a  more  pre¬ 
cise  specification  of  what  tasks  are  and  how  they  will  be  used. 

The  moved  Method 

Issues 

•  The  OMSC  does  not  state  the  parameters  of  the  method.  Potential 
parameters  include: 

•  New  coordinates  (either  relative  or  absolute) 

•  Time  until  new  coordinates  are  reached 

•  The  specification  does  not  state  whether  the  next  location  is  known 
in  advance  (in  which  case  parameters  might  not  be  needed). 

•  The  OMSC  does  not  describe  necessary  granularity  of  movement  (that  is, 
minimum  length  or  time  of  movement). 

Recommended 
Changes  to  the 
OMSC 

The  OMSC  should  included  a  parameterized  model  of  movement,  one  that 
addresses  granularity. 

ThedetermineAttritionO  Method 

1 ssues 

The  OMSC  does  not  specify  units  for  attrition  (percentage?  absolute  val¬ 
ues?  specific  entities  removed?) 

Recommended 
Changes  to  the 
OMSC 

The  OMSC  should  specify  ways  in  which  attrition  may  be  stated.  Where 
applicable,  the  OMSC  should  specify  units  and  precision  for  attrition. 

The  UnitGeometry  Class 


ThegetShapeO  Method 

Issues 

The  OMSC  does  not  indicate  the  nature  or  generality  of  bounding  shapes. 

Recommended 
Changes  to  the 
OMSC 

The  OMSC  should  define  the  result  of  getShapeO  to  be  a  class  Shape.  Shape 
should  have  subclasses  such  asRectangle,  Circle,  etc.  This  structure  will 
support  current  needs  while  providing  for  future  enhancements. 

ThegetOrientationO 

1  Method 

Issues 

•  The  OMSC  does  not  state  the  units  of  orientation.  Presumably 
orientation  is  in  degrees. 

•  TheAlCDM  does  not  model  orientation. 
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The  Intel  Class 


The  collect!)  Method 

Issues 

•  The  OMSC  does  not  specify  how  the  organic  sensor  assets  of  a  unit  are 
defined. 

•  Detection  involves  more  than  turning  on  a  sensor.  The  sensor  is  typically 
directed  against  some  feature,  other  organization,  etc.  The  OMSC  does 
not  define  how  search  capabilities  may  be  effected  other  than  turning 
them  on. 

•  The  AlCDM  does  not  model  sensor  activation  and  deactivation. 

Recommended 
Changes  to  the 
AlCDM 

The  AlCDM  needs  attributes  that  give  the  state  of  a  sensor,  as  well  as 
other  possible  sensor-specific  characteristics  (orientation,  e.g.) 

Recommended 
Changes  to  the 
OMSC 

•  The  OM  SC  must  specify  how  the  sensor  assets  of  a  unit  are  defi  ned. 

•  The  OM  SC  must  specify  how  the  sensor  assets  of  a  unit  may  be  used. 

ThereportContacts! 

)  Method 

Issues 

•  The  OMSC  does  not  specify  the  nature  of  results,  nor  how  they  might  be 
used.  The  only  other  method  associated  with  a  Unit  that  might  use 
intelligence  is  C2.cloC2(). 

•  Typically,  M&S  systems  can  model  any  entity  detected  by  intelligence. 

The  Al  CDM  can  only  record  such  an  entity  if  it  is  a  candidate  target. 

Recommended 
Changes  to  the 
AlCDM 

•  The  AlCDM  needs  to  model  entities  recorded  by  intelligence  but  not  yet 
known  to  be  (candidate)  targets. 

•  The  codes  associated  with  feature  need  to  account  for  intelligence. 

•  The  proposed  AlCDM  entity  INFORMATION-REFERENCE  may  be  useful  for 
modeling  intelligence  results.  The  domain  values  of  the  INFORMATION- 
REFERENCE-CATEGORY-CODE  attribute  would  need  to  be  extended  to 
account  for  intelligence. 

Recommended 
Changes  to  the 
OMSC 

The  OMSC  needs  a  class  that  acts  as  a  superclass  of  possible  results  for  the 
collectO  method. 

D.2  Platform  Standard  Object 


The  Platform  Class 


ThegetTypeO  Method 

Issues 

The  OMSC  does  not  define  what  a  type  designation  is.  Assuming  that  Plat¬ 
form  is  a  virtual  class  and  that  actual  platform  instances  would  be  mem¬ 
bers  of  subtypes  of  Platform,  the  type  designation  is  probably  just  an  iden¬ 
tify!  ng  stri  ng  that  gives  the  name  of  the  subtype. 

Recommended 
Changes  to  the 
AlCDM 

For  convenience,  the  AlCDM  may  need  to  be  amended  to  include  a  new  en¬ 
tity  class  PLATFORM.  Subtypes  of  this  entity  would  include  all  AlCDM  enti¬ 
ties  that  areconsidered  platforms  in  the  OMSC.  (TheDDA  contains  sepa¬ 
rate  entities  for  ships  and  satellites.  We  recommend  including  these  enti¬ 
ties  in  the  AlCDM  to  address  M&S  requirements  for  water  and  space  plat¬ 
forms.) 
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Recommended 
Changes  to  the 
OMSC 

The  OMSC  needs  to  enumerate  at  least  a  partial  list  of  valid  platform 
types. 

ThegetLocationO  Method 

See  the  description  of  thegetLocationO  method  for  the  Unit  class. 

The  gets ide()  Method 

See  the  description  of  thegetSideO  method  for  the  Unit  class. 

TheassessDamageO  Method 

Issues 

•  The  OM  SC  does  not  specify  the  types  of  objects  that  might  cause  damage. 

•  The  OMSC  does  not  specify  how  the  amount  of  damage  is  determined. 

•  The  description  states  that  the  method  calculates  damage  caused,  but 
there  is  no  method  associated  with  a  Platform  that  actually  causes 
damage. 

•  The  OMSC  does  not  specify  units  in  which  damage  is  measured. 

•  The  OMSC  does  not  specify  how  the  object  that  caused  the  damage  is 
identified,  if  more  than  one  object  can  cause  damage,  or  what  an  object 
might  be  (can  damage  to  a  truck  come  from  a  rock?  If  not,  how  does  one 
model  such  potential  damage?). 

•  This  method  assesses  damage.  How  is  damage  caused?  What  entities  are 
consumed  in  causing  it? 

•  TheAlCDM  codes  for  damage  to  materiel,  facilities,  and  peoplearenot 
adequate  to  model  the  types  of  damage  possi  ble  in  an  M  S(S  system. 

Recommended 

TheAlCDM  needs  codes  for  materiel,  facilities,  and  people  that  model  the 

Changes  to  the 

types  of  damage  possi  ble  to  such  entities  i  n  M  S(S  systems. 

AlCDM 

Possibly  some  types  of  damage  are  complex  enough  to  warrant  creation  of  a 
new  entity,  with  attributes  to  model  the  various  types  of  damage. 

Recommended 
Changes  to  the 
OMSC 

The  OM  SC  needs  a  model  of  damage. 

The  Sensor  Class 


ThegetMaxRangeO  Method 

Issues 

The  OMSC  does  not  prescribe  the  units  of  range. 

Recommended 
Changes  to  the 
OMSC 

The  OM  SC  should  standardize  the  units  and  precision  of  range. 

ThegetOrientationO 

1  Method 

See  the  description  of  thegetOrientationO  method  for  theUnitGeometry  class. 

ThegetContactsO  Method 

Issues 

•  A  Platform  does  not  have  a  location.  Without  a  location,  how  can  the 
contacts  be  determined?  (The  Unit  class  has  a  collection  of  Platform 
instances,  and  moreover  may  be  hierarchically  composed  of  Unit 
i  nstances.  Perhaps  a  Platform's  location  is  always  the  center  of  mass  of 
its  containing  Unit,  where  the  Unit's  granularity  is  small  enough  to 
resolve  the  problem  of  locati  ng  contacts.) 

Recommended 
Changes  to  the 
OMSC 

The  OM  SC  needs  to  clarify  the  method  by  which  contacts  are  gathered,  and 
whether  it  requiresa  location;  if  it  does,  the  OMSC  needs  to  clarify  how  the 
location  of  a  platform  is  determined. 
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The  activated  and  deactivated  Methods 

Issues 

The  Al  CDM  does  not  model  whether  a  sensor  is  on  or  off. 

Recommended 
Changes  to  the 
AlCDM 

The  Al  CDM  needs  to  model  sensor  state. 

The  Weapon  Cl 

ass 

ThegetMaxRangeO  Method 

Issues 

The  OMSC  does  not  prescribe  the  units  of  range. 

Recommended 
Changes  to  the 
OMSC 

The  OMSC  needs  to  define  the  units  and  precision  of  range. 

The ioadO  Method 

Issues 

•  The  OMSC's  description  of  loading  "a"  munition  seems  oriented  towards 
particular  types  of  weapons,  like  artillery.  Is  that  the  intent? 

•  The  AlCDM  does  not  model  whether  or  not  a  weapon  is  loaded. 

Recommended 
Changes  to  the 
AlCDM 

The  AlCDM  needs  to  be  able  to  model  thestateof  a  weapon. 

Recommended 
Changes  to  the 
OMSC 

The  OM  SC  needs  to  clarify  the  range  of  weapons  to  which  this  operation 
can  be  applied. 

TheengageTargetO  Method 

Issues 

•  The  OMSC  does  not  indicate  how  long  the  weapon-firing  event  takes.  Is 
this  captured  in  a  subtype?  It  should  be  a  virtual  method. 

•  There  is  no  method  to  determine  whether  weapon  firing  has  ended. 

•  Is  aiming  part  of  engaging  a  target?  There  is  no  aim()  method. 

•  The  AlCDM  does  not  model  weapon  firing. 

Recommended 
Changes  to  the 
AlCDM 

The  AlCDM  needs  to  model  weapon  firing.  More  precisely,  it  needs  to 
model  the  status  of  a  weapon,  i  ncl  udi  ng  bei  ng  i  n  a  fi  ri  ng  state  (whatever 
that  might  mean  for  a  particular  weapon). 

Recommended 
Changes  to  the 
OMSC 

The  OMSC  needs  a  model  of  weapon  firing.  The  model  should  allow  a  sys¬ 
tem  to  determi  ne  if  a  weapon  has  been  fi  red,  where  it's  poi  nti  ng,  and  thi  ngs 
like  that. 

The  PlatformFrame  Class 


The  gets ignatureO  Method 

Issues 

•  The  OMSC  lists  ©camples  of,  but  does  not  describe  the  full  range  of, 
signatures.  Nor  does  it  provide  a  general  means  to  encapsulate 
signatures  (e.g.,  a  virtual  class  Signature). 

•  The  method's  description  is  worded  as  if  a  target  has  a  single  signature. 
Can't  a  target  have  multiple  signatures? 

•  The  AlCDM  can  model  only  a  cross-sectional  area  signature. 

Recommended 
Changes  to  the 
AlCDM 

TheAlCDM  should  increasethe  range  of  signatures  that  it  can  model.  (The 
DDA  has  attributes  to  keep  track  of  height,  weight,  etc.  that  the  AlCDM 
lacks.) 

Recommended 
Changes  to  the 
OMSC 

The  OMSC  should  define  a  virtual  dass  Signature,  which  would  be  the 
value  returned  by  gets  ignatureO.  Sensors  would  return  subclasses 
(ThermalSignature,  Acoustics ignature,  etc). 
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The  Movement  Class 

ThegetVelocity(),changeVelocity(),  and  moveToO  Methods 

See  the  description  of  thegetVelocityO  method  for  the  Unit  class. 

The  Logistics,  Suppiy,  Maintenance,  and  Communications  Ciasses 

See  the  description  of  these  classes  for  the  Unit  standard  object. 


D.3  Location  Standard  Object 

The  issues  surrounding  locations  have  been  discussed  in  Section  D.l. 


D-9 


Appendix  E.  Implementation  of  Recommendations 
in  Later  Versionsof  the AlCDM 


As  noted  in  the  main  portion  of  this  report,  IDA  performed  the  alignment  analysis  using 
the  March  1,  2000  version  of  the  AICDM.  The  AICDM,  however,  is  meant  to  continue 
evolving  to  encompass  any  new  valid  data  requirement.  As  a  result,  some  of  the  recom¬ 
mendations  made  during  the  preparation  of  this  report  have  been  already  incorporated 
into  the  AICDM,  and  data  package  proposals  for  submission  to  the  DoD-8320  standardi¬ 
zation  process  have  been  prepared.  This  Appendix  shows  the  AICDM’s  status  as  of  Janu¬ 
ary  2001. 

E.l.  Velocity  and  Orientation  Attributes 

This  report  has  made  two  recommendations  regarding  the  need  for  the  AICDM  to  have 
attributes  that  can  model  velocity  and  orientation: 

Section  7.1.1:  The  AICDM  needs  to  be  able  to  model  the  velocity  of  (at  least)  the  PERSON, 
MATERIEL,  and  ORGANIZATION  entities. 

Section  D.l:  The  AICDM  should  include  information  on  orientation.  It  is  likely  that  ori¬ 
entation  must  be  specified  for  several  types  of  entities  (organizations  and  plat¬ 
forms,  at  least).  Given  the  attributes  of  POINT,  which  include  precision,  it  is  proba¬ 
bly  necessary  to  create  a  new  entity,  ORIENTATION,  containing  attributes  that  ex¬ 
press  orientation.  Instances  of  this  entity  would  be  linked  to  an  ORGANIZATION  (or 
PLATFORM)  through  a  many-to-many  relationship  via  an  intermediate  ORGANIZATION- 
ORIENTATION  entity  (similar  to  the  relationship  between  ORGANIZATION  and  LOCA¬ 
TION).  An  orientation  may  be  absolute  or  relative  (e.g.,  “in  front  of’),  and  the 
AICDM  should  be  able  to  model  both  types. 

The  January  2001  version  of  the  AICDM  includes  several  attributes  to  model  velocity 
and  orientation.  See  Table  E-1. 

Table  E-1.  New  AICDM  Attributes  to  Model  Velocity  and  Orientation 


Entity 

New  Attributes 

FACILITY12 

FACILITY-POINT  BEARING  ANGLE 

FACILITY-POINT  SPEED  RATE 

The  analysis  in  Appendix  A  uses  a  FAC  ILITY  to  model  a  stationary  entity.  However,  the  Navy  proposes 
to  model  a  ship  as  a  FACILITY. 
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ORGANIZATION 

ORGANIZATION-POINT  BEARING  ANGLE 

ORGANIZATION-POINT  SPEED  RATE 

MATERIEL 

MATERIEL-POINT  BEARING  ANGLE 

MATERIEL-POINT  SPEED  RATE 

Figure  E-1  shows  these  attributes,  the  entities  containing  them,  and  selected  relationships 
of  these  entities  to  key  AICDM  entities. 


MATERIEL-POINT 
MATERIEL-POINT  IDENTIFIER 
MATERIEL  IDENTIFIER  (FK) 

LOCATION  IDENTIFIER  (FK) 

ORGANIZATION  IDENTIFIER  (FK) 
located  at  MATERIEL-POINT  STATUS  CODE 

- •  MATERIEL-POINT  BEGIN  CALENDAR  DATE-TIME 

MATERIEL-POINT  DESCRIPTION  TEXT 
MATERIEL-POINT  END  CALENDAR  DATE-TIME 
MATERIEL-POINT  PURPOSE  CODE 

MATERIEL-POINT  BEARING  ANGLE  - 

MATERIEL-POINT  SPEED  RATE 

MATERIEL-POINT  DATA  REPORTED  CALENDAR  DATE-TIME 
MATERIEL-POINT  CREDIBILITY  CODE 
MATERIEL-POINT  ENCLOSURE  RADIUS  DIMENSION 


ORGANIZATION-POINT _ 

ORGANIZATION-POINT  IDENTIFIER 
ORGANIZATION  IDENTIFIER  (FK) 

LOCATION  IDENTIFIER  (FK) 

REPORTING  (FK) 

ORGANIZATION-POINT  STATUS  CODE 
ORGANIZATION-POINT  BEGIN  CALENDAR  DATE-TIME 
ORGANIZATION-POINT  END  CALENDAR  DATE-TIME 
ORGANIZATION-POINT  PURPOSE  CODE 
ORGANIZATION-POINT  BEARING  ANGLE 
ORGANIZATION-POINT  SPEED  RATE 

ORGANIZATION-POINT  DATA  REPORTED  CALENDAR  DATE-TIME 
ORGANIZATION-POINT  CREDIBILITY  CODE 
ORGANIZATION-POINT  ENCLOSURE  RADIUS  DIMENSION 
ORGANIZATION-POINT  DESCRIPTION  TEXT 
ORGANIZATION-POINT  TYPE  CODE 


MATERIEL _ 

MATERIEL  IDENTIFIER 

OBJECT-ITEM  IDENTIFIER  (FK) 

MATERIEL-ITEM  IDENTIFIER  (FK) 

MATERIEL-SERIALIZED-ITEM  CONTROL  NUMBER  IDENTIFIER  (FKt 

MATERIEL  ALTERNATE  IDENTIFIER 

MATERIEL  CATEGORY  CODE 

MATERIEL  FRIEND  FOE  CODE 

MATERIEL  Lot  Identification  Text 


FACILITY _ 

I  FACILITY  IDENTIFIER 


OBJECT-ITEM  IDENTIFIER  (FK) 

FACILITY-TYPE  CODE  (FK) 

GEOLOCATION  CODE  (FK) 

FACILITY  Category  Code 

FACILITY  CONSTRUCTION  PERMANENCY  CATEGORY  CODE 
FACILITY  ELECTRICAL  SERVICE  CAPACITY  RATE 
FACILITY  EXTERNAL  SEWAGE  CONNECTION  INDICATOR  CODE 
FACILITY  NAME 

FACILITY  SEWAGE  DRAINAGE  RATE 
FACILITY  WATERFLOW  SERVICE  CAPACITY  RATE 
FACILITY  FRIEND  FOE  CODE 
FACILITY  A  LA  CARTE  SERVING  CODE 
FACILITY  CONSTRUCTION  BEGIN  DATE 
FACILITY  CONSTRUCTION  END  DATE 
FACILITY  TYPE  CODE 


provides 


provides 


located  at 

1  1 
FACILITY-POINT 
FACILITY-POINT  IDENTIFIER 
FACILITY  IDENTIFIER  (FK) 

LOCATION  IDENTIFIER  (FK) 

REPORTING  (FK) 

FACILITY-POINT  STATUS  CODE 
FACILITY-POINT  BEGIN  CALENDAR  DATE-TIME 
FACILITY-POINT  ENCLOSURE  RADIUS  DIMENSION 
FACILITY-POINT  END  CALENDAR  DATE-TIME 
FACILITY-POINT  PURPOSE  CODE 
FACILITY-PONT  BEARING  ANGLE 
FACILITY-POINT  SPEED  RATE 

FACILITY-POINT  DATA  REPORTED  CALENDAR  DATE-TIME 
FACILITY-POINT  CREDIBILITY  CODE 
FACILITY-POINT  DESCRIPTION  TEXT 


provides 


ORGANIZATION _ 

ORGANIZATION  IDENTIFIER 

'  IDENTIFICATION-FRIEND-FOE  CODE  (FK) 
Principal  EQUIPMENT-TYPE  Code  (FK) 

ORGANIZATION  CATEGORY  CODE 
ORGANIZATION  CLASSIFICATION  CODE 
ORGANIZATION  DESCRIPTION  TEXT 
ORGANIZATION  DURATION  TYPE  CODE 
ORGANIZATION  PRIMARY  ACTIVITY  CODE 
ORGANIZATION  TYPE  CODE 
OBJECT-ITEM  IDENTIFIER  (FK) 


Figure  E-1.  Velocity  and  Bearing  Angle  Attributes  for  FACILITY,  MATERIEL,  and 
ORGANIZATION  in  the  J  anuary  2001  version  of  the  AICDM 

This  data  proposal  package  is  still  undergoing  technical  review.  A  request  to  model 
PERSON-POINT  in  the  same  way  as  the  three  entities  mentioned  above  has  already  been 
submitted.  Furthermore,  analysis  with  respect  to  maritime  operations  appears  to  warrant 
extending  the  same  approach  to  FEATURE-POINT.'^ 


The  March  2000  version  of  the  AICDM  modeled  an  organization’s  center  of  mass  as  a  LOCATION,  one 
subtype  of  which  was  POINT.  The  January  2001  version  of  the  AICDM  relates  a  battlefield  object’s 
center  of  mass  directly  to  a  POINT. 
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E .2.  Externalization  of  I DE NTI FI CATI ON-FRI END-FOE 

This  report  has  made  a  reeommendation  regarding  the  AICDM’s  ability  to  model  eoali- 
tion  forees: 

Section  7.1.1:  The  AICDM  should  enhanee  its  ability  to  model  friends  and  foes.  One  ap- 
proaeh  is  to  add  values  FACTION  and  COALITION  to  the  IDENTIFICATION-FRIEND-FOE 
CODE  attribute  of  the  ORGANIZATION  entity  Another  is  to  externalize  the  FRIEND- 
FOE  attributes. 

The  January  2001  version  of  the  AICDM  has  already  replaeed  the  table  attributes  for 
IDENTIFCATION-FRIEND-FOE  that  existed  in  ORGANIZATION  and  FEATURE  by  a  foreign  key 
eoming  out  of  the  externalized  entity  IDENTIFICATION-FRIEND-FOE.  See  Figure  E-2.  Similar 
replaeements  will  oeeur  as  the  paekages  for  the  MATERIEL,  PERSON  and  FACILITY  domains 
are  prepared. 
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IDENTIFICATION-FRIEND-FOE 
IDENTIFICATION-FRIEND-FOE  CODE 


applies  to 


i 

FEATURE 

FEATURE  IDENTIFIER 


OBJECT-ITEM  IDENTIFIER  (FK) 
IDENTIFICATION-FRIEND-FOE  CODE  (FK) 
FEATURE-TYPE  IDENTIFIER  (FK) 

FEATURE  CATEGORY  CODE 

FEATURE  NAME 

FEATURE  DESCRIPTION  TEXT 

FEATURE  EXISTENCE  END  CALENDAR  DATE-TIME 

FEATURE  EXISTENCE  BEGIN  CALENDAR  DATE-TIME 

FEATURE  ENEMY  ACTIVITY  CODE 

FEATURE  COUNTERMEASURE  CODE 


applies  to 


ORGANIZATION 


ORGANIZATION  IDENTIFIER 


IDENTIFICATION-FRIEND-FOE  CODE  (FK) 
Principal  EQUIPMENT-TYPE  Code  (FK) 
ORGANIZATION  CATEGORY  CODE 
ORGANIZATION  CLASSIFICATION  CODE 
ORGANIZATION  DESCRIPTION  TEXT 
ORGANIZATION  DURATION  TYPE  CODE 
ORGANIZATION  PRIMARY  ACTIVITY  CODE 
ORGANIZATION  TYPE  CODE 
OBJECT-ITEM  IDENTIFIER  (FK) 


Figure  E-2.  Externalization  of  IDENFICATION-FRIEND-FOE 
i  n  the  latest  version  of  the  Al  C  DM 

The  current  enumerated  domain  values  for  IDE NTIFCATION -FRIEND-FOE  CODE  are:  ASSUMED 
FRIEND,  FRIEND,  HOSTILE,  J  OKER,  FAKER,  NEUTRAL,  PENDING,  and  SUSPECT.  Review  of  the 
proposed  values  FACTION  and  COALITION  maybe  necessary. 
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